E

in Sicherheits-Deep-Dive, inspiriert von einer Prozessgrafik – und ergänzt um das, was die Praxis wirklich ausmacht

Wer heute an der Kasse sein Smartphone an das Terminal hält, löst damit ein erstaunlich komplexes Zusammenspiel aus Kryptografie, Hardware-Sicherheitskomponenten, Token-Diensten der Karten­netzwerke, Bankprüfungen und Händler-Backends aus. Von all dem bekommt man in der Regel nichts mit – und das ist gut so. Die eingangs gezeigte Prozessgrafik macht einen wichtigen Punkt sichtbar: Apple Pay und Google Pay verfolgen ähnlichen Zweck, aber unterscheiden sich im Architekturdetail, vor allem bei der Frage, wo sensible Informationen liegen und wie eine Zahlung kryptografisch gebunden wird. Aus dieser scheinbar kleinen Designentscheidung erwachsen spürbare Unterschiede in Angriffsfläche, Datenschutz und Betriebsmodell.

In diesem Beitrag zerlegen wir die Abläufe hinter beiden Wallets so, dass sie auch ohne Spezialvorwissen verständlich bleiben – und beleuchten, was die Grafik gut trifft, wo sie vereinfacht und was in der gelebten Praxis noch dazu gehört. Das Ergebnis vorweg: Beide Lösungen sind sehr sicher. Apple spielt seine Stärken bei strikt hardwaregebundener Tokenisierung und Datensparsamkeit aus, während Google durch Plattform-Breite und Flexibilität überzeugt – auf Kosten einer etwas größeren Varianz in der technischen Umsetzung, die Sicherheits- und Compliance-Teams bewusst managen müssen.

1. Der gemeinsame Nenner: Tokenisierung statt Kartennummer

Bevor wir die Unterschiede betrachten, lohnt der Blick auf das, was identisch ist – und den eigentlichen Sicherheitsgewinn mobiler Wallets erklärt. Weder Apple Pay noch Google Pay übermitteln beim Bezahlen die echte Primärkontonummer (PAN) Ihrer Karte. Stattdessen kommt eine Netzwerk-Tokenisierung zum Einsatz:

• Dem physischen Kartendatensatz wird beim Provisionieren in der Wallet ein Ersatz-Identifier zugeordnet. Bei Apple heißt er in der Dokumentation Device Account Number (DAN), in ISO-/Kartenwelt oft DPAN (Device PAN) genannt.
• Dieser Token ist gerätsspezifisch. Ein und dieselbe Karte ergibt pro Gerät einen eigenen Token.
• Für jede Transaktion wird zusätzlich ein dynamischer Kryptogramm-Wert erzeugt (man kann ihn sich als Einmal-Signatur vorstellen), der nur in Kombination mit dem korrekten Token und den Transaktionsparametern gültig ist.

Damit gilt: Selbst wenn ein Händler kompromittiert würde, fände ein Angreifer dort keine echte Kartennummer, sondern nur einen Token, der ohne den zugehörigen Schlüsselbund nutzlos ist. Und weil der Token je Gerät anders ist, lassen sich Lecks nicht sinnvoll „recyceln“.

Diese Grundidee teilen beide Ökosysteme. Die Unterschiede beginnen dort, wo der Token liegt, wie er erzeugt wird und wie der Einmal-Nachweis gebaut wird.

2. Apple Pay im Sicherheits-Querschnitt

2.1 Architektur in einem Satz

Apple Pay speichert den Kartentoken (DAN/DPAN) im „Secure Element“ des Geräts und erzeugt den Transaktions-Kryptogrammwert dort hardwarebasiert; Apple selbst sieht die PAN nicht und kann aus den übertragenen Daten keine personenbezogenen Kaufprofile bauen.

2.2 Was bedeutet „Secure Element“ konkret?

Im iPhone (und auch in der Apple Watch) steckt ein isolierter Chipbereich, das Secure Element (SE). Er ist physisch und logisch vom restlichen Betriebssystem abgeschottet. Der SE hält:

• den gerätsspezifischen Zahlungstoken (DAN/DPAN),
• die Schlüsselmaterialien, mit denen pro Zahlung das dynamische Kryptogramm (ein sog. Application Cryptogram) gerechnet wird,
• die Policy, dass ohne erfolgreiche Benutzerauthentifizierung (Touch ID/Face ID/Code) keine Freigabe erfolgt.

Wichtig: Apple speichert die echte Kartennummer nicht auf dem Gerät und nicht auf Apple-Servern. Beim Hinzufügen einer Karte laufen Prüfdaten über Apple-Infrastruktur zur Bank bzw. zum Token Service Provider (TSP) der Netzwerke; am Ende landet auf dem Gerät nur der Token – nicht die PAN.

2.3 Was passiert an der Kasse?

Beim Tap an der NFC-Kasse läuft vereinfacht Folgendes ab:

1. Das Terminal fordert eine Zahlung mit Betrag/Währung an.
2. Das iPhone authentifiziert den Nutzer (Biometrie/Code).
3. Im Secure Element wird aus Token + Transaktionsparametern + einem Zähler ein Einmal-Kryptogramm generiert.
4. Das Terminal erhält Token + Kryptogramm, nicht die PAN.
5. Über Acquirer und Netzwerk geht die Anfrage an Bank/TSP, die das Kryptogramm prüfen und freigeben.

Auch offline-nah (bei kurzzeitig gestörter Konnektivität) kann Apple Pay Transaktionen liefern, weil der kryptografische Anteil lokal im SE entsteht und nur auf Netzwerkseite verifiziert wird.

2.4 Apple Pay im Web und in Apps

In Apps oder im Browser („Apple Pay on the Web“) wird ein Zahlungs-Token erzeugt, der zusätzlich mit dem Public Key des Händlers verschlüsselt ist. Der Händler kann den Token nur über sein Payment-Gateway entschlüsseln/weiterleiten. Apple sieht den Inhalt nicht. Das schützt vor Abgreifen sensibler Felder im Browser.

2.5 Datenschutz-Philosophie

Apple betont: Transaktionsdaten sind für Apple nicht personenbezogen auswertbar. Apple erfährt zwar, dass eine Transaktion stattfand (z. B. zur Geräteverwaltung, für Verlust-/Diebstahl-Funktionen und zur Betrugsprävention auf Systemebene), aber nicht wo, was und zu welchem Preis – diese Informationen gehen an Bank und Händler, nicht an Apple. Für viele Unternehmen ist das ein schlagendes Argument, wenn es um Datenminimierung geht.

3. Google Pay / Google Wallet im Sicherheits-Querschnitt

3.1 Architektur in einem Satz

Google Pay (heute im Kern die Google Wallet-Zahlungsfunktion) nutzt ebenfalls Tokenisierung und dynamische Kryptogramme, setzt je nach Gerät/Hersteller entweder auf ein hardwarebasiertes Secure Element („Android Ready SE“/eSE/StrongBox) oder auf Host Card Emulation (HCE) mit serversynchronisierten Token-Blöcken. Zusätzlich werden Kartendaten oft im Google-Konto verwaltet – praktisch für Multi-Device-Nutzung, aber mit anderen Datenschutz-Voraussetzungen als bei Apple.

3.2 Fragmentierte Hardware – zwei Schutzpfade

Android ist ein Ökosystem. Moderne Pixel- und viele Premium-Geräte besitzen ein eSE (embedded Secure Element) ähnlich dem iPhone. Hier liegen Token und Schlüssel auf dem Gerät, Kryptogramme werden vor Ort produziert.
Ältere/Einsteiger-Modelle oder spezielle Länderkonfigurationen nutzen teils HCE: Der virtuelle Kartenchip wird im Betriebssystem emuliert; die Token-Vorräte (sog. „Token Keys“ oder „Applets“) werden vom Server auf das Gerät „nachgeladen“. Sicherheitsanker sind dann verschlüsselte Kanäle, Geräte-Attestation (Play Integrity/SafetyNet), TEE (Trusted Execution Environment) und strenge Limits, wann das Gerät ohne frische Serverfreigabe zahlen darf.

Beide Wege sind sicher, aber die Angriffsfläche variiert: Ein richtig angebundenes eSE reduziert die Abhängigkeit vom Server und minimiert den Code-Umfang, der an der Zahlung beteiligt ist; HCE stützt sich stärker auf OS-Sicherheitsgrenzen und Online-Kontrolle. Deshalb setzen Banken/Netzwerke Risikoparameter wie „HCE-Limit nur bis Betrag X“ oder „höhere Online-Pflicht“.

3.3 Konto-Komfort vs. Datensparsamkeit

Google bietet den Vorteil, Zahlungsmittel im Google-Konto zu verwalten. Karten „folgen“ damit leichter auf neue Geräte, in Chrome-Autofill oder in anderen Google-Diensten. Diese Komfort-Synchronisation bedeutet aber auch: Mehr Metadaten liegen beim Plattformanbieter als im Apple-Modell. Google dokumentiert, wie sich Datennutzung konfigurieren lässt; für Unternehmen mit strikter Privacy-Policy ist das ein Abwägungspunkt.

3.4 Zahlung an der Kasse und online

Ablauf an der Kasse ähnelt Apple Pay: Token + dynamisches Kryptogramm gehen zum Terminal. Je nach eSE/HCE-Pfad entsteht der Kryptogramm-Wert auf dem Gerät oder mithilfe serversynchronisierter Token-Slots.
Online bietet die Google Pay API Bezahl-Tokens, die Händler/PSPs entschlüsseln. Auch hier gilt: Keine PAN im Händler-System – ein großer Compliance-Gewinn (PCI-DSS).

4. Die Prozessgrafik richtig lesen – wo sie verkürzt und was sie lehrt

Die Grafik stellt Apple auf der linken und Google auf der rechten Seite gegenüber. Links wandert die Karteneingabe direkt „ins Chip-Symbol“ des iPhones, rechts „zum Google-Server“. Daraus könnte der Eindruck entstehen, Google speichere grundsätzlich Kartendaten serverseitig, während Apple dies nie täte. So simpel ist es nicht:

• Apple: Richtig ist, dass Apple die PAN nicht speichert und der Token im Secure Element liegt. Beim Provisionieren fließen allerdings verschlüsselte Prüfwerte über Apple-Systeme zum Token Service der Netzwerke/Banken. Aus Sicht des Datenschutzes ändert das nichts Wesentliches: Die PAN wird nicht bei Apple abgelegt, und Apple kann aus diesen Prozessen keine Kaufbibliothek bauen.
• Google: Die Darstellung „erst Server, dann Gerät“ erinnert an die HCE-Variante, bei der Token-Schlüsselvorräte mit dem Server synchronisiert werden. Viele moderne Android-Geräte mit eSE verarbeiten den sensiblen Teil gerätelokal – die „Server zuerst“-Optik passt dort nicht. Was bleibt: Google betreibt mehr Konto- und Ökosystem-Funktionalität, wodurch mehr Metadaten im Google-Konto aggregiert werden können, wenn man das nicht aktiv begrenzt.

Die Lehre aus der Grafik bleibt dennoch wertvoll: Apple verfolgt eine radikal hardwaregebundene Strategie mit sehr enger Plattformkontrolle; Google bietet ein leistungsfähiges, aber breiteres Spektrum an Sicherheits­pfaden – aus Nutzersicht komfortabel, aus Risiko­sicht heterogener. Für Endanwender ist beides sicher; für Unternehmens- und Compliance-Teams lohnt die bewusste Wahl der Flotten-Hardware und der Richtlinien.

5. Wo echte Risiken liegen – und wie beide Wallets sie abwehren

5.1 Verlust oder Diebstahl des Geräts

Sowohl Apple als auch Google koppeln Zahlungen an starke lokale Authentifizierung. Ohne Face ID/Touch ID/Passcode (Apple) bzw. System-Biometrie/PIN (Android) geht nichts – kontaktlose Kleinstbeträge ohne Entsperren sind in den Wallets standardmäßig nicht vorgesehen.
Zudem lassen sich Geräte remote sperren, Karten entkoppeln oder neu tokenisieren. Bei Apple geschieht das über „Mein iPhone suchen“ bzw. iCloud; bei Google über „Find My Device“ und das Google-Konto.

5.2 Händler- oder Gateway-Kompromittierung

Kommt regelmäßig vor – und genau hier glänzt Tokenisierung: Der Händler sieht nie die PAN, sondern den DPAN + Kryptogramm. Einbrecher können damit keine Kartendubletten herstellen. Missbrauch müsste über kompromittierte Händlerkonten und Abrechnungsbetrug erfolgen, was Acquirer und Netzwerke mit Verhaltensanalytik inzwischen sehr gut im Blick haben.

5.3 Rogue Terminals und Relay-Angriffe

Theoretisch kann jemand ein Terminal imitieren oder eine Verbindung verlängern. In der Praxis verhindern Transaktionsbindung, NFC-Protokollgrenzen, begrenzte Reichweiten, die Notwendigkeit der Nutzerfreigabe und zeitliche Fenster das Ausnutzen. Beide Wallets erzeugen Kontext-gebundene Kryptogramme, die nicht wiederverwendbar sind.

5.4 Jailbreak/Root und Gerätezustand

Apple sperrt jailbreaked Geräte für sensible Operationen recht rigoros. Android setzt auf Play Integrity/SafetyNet: Apps und Zahlungsflüsse erhalten Attestierungen über Gerätezustand, Bootloader-Status und Patch-Level. Banken können risikobasiert entscheiden, ob sie Zahlungen unter bestimmten Zuständen verweigern. Für Unternehmensflotten ist hier MDM Pflicht: Nur zertifizierte Geräteklassen, Mindest-Patch-Level, Bootloader-Lock und MFA-Erzwingung.

5.5 Phishing und Social Engineering

Wallets lösen Kartendaten-Phishing nicht vollständig; sie verlagern das Risiko. Wer auf einem Phishing-Screen eine Karte in die Wallet „hinzufügt“, kann sich Probleme einhandeln. Apple und Google arbeiten mit Push-Verifikationen, Bankfreigaben und Out-of-Band-Checks, um das zu erschweren. Unternehmen sollten Mitarbeitende sensibilisieren und App-Installationen aus unbekannten Quellen blockieren.

6. Praxisrealität im Unternehmen: Welche Wallet passt zu welcher Strategie?

iOS/Apple Pay ist für viele Unternehmen die erste Wahl, wenn Kontrollierbarkeit und datensparsame Voreinstellungen dominieren. Die Homogenität der Hardware (eSE überall, definierte Update-Politik, enge Betriebssystem-Kontrolle) macht Risikomodelle einfacher. Wer BYOD lebt oder global in unterschiedlichste Android-Preis-/Leistungsklassen skaliert, kann mit Google-Wallet/Pay hervorragend fahren – unter zwei Bedingungen: Man wählt geeignete Geräteklassen (idealerweise mit Android Ready SE/StrongBox) und erzwingt Sicherheitsrichtlinien konsequent (MDM/EMM, Patch-SLAs, Play-Integrity-Checks).

Gerade im Einzelhandel und bei großen Außendiensten hat die Möglichkeit, Zahlungsmittel über das Google-Konto zu synchronisieren, einen Charme: Gerätewechsel gehen schneller, das Onboarding wirkt leichtfüßig. Im Gegenzug verlangt der Datenschutz oft engere Richtlinientexte und Transparenz, welche Metadatenverarbeitung in Google-Diensten deaktiviert oder eingeschränkt wird.

7. Online-Bezahlen: Apple Pay JS vs. Google Pay API – derselbe Schutzgedanke

Abseits der NFC-Kasse spielen Wallets ihre Stärken auch im Web und in Apps aus. Aus Sicherheits- und PCI-Sicht sind drei Dinge entscheidend:

1. Kein Händlerkontakt mit PAN: Beide APIs liefern Bezahl-Tokens, keine Klartext-Kartendaten.
2. Verschlüsselung auf Händler-Schlüssel: Apple kapselt den Payment-Blob standardmäßig mit dem Public Key des Händlers; Google schützt die Struktur je nach Integrationspfad ähnlich, oft über PSP-spezifische Schlüsselkapsel.
3. 3-D Secure 2 / SCA: In Europa greift die starke Kundenauthentifizierung. Wallets integrieren sie auf komfortable Weise, weil die lokale Biometrie als starke Authentifizierung zählt.

Für Händler ergibt das einen dreifachen Gewinn: höhere Conversion (weniger Reibung beim Checkout), geringere Fraud-Rate (dank Token + Kryptogramm + SCA) und weniger PCI-Last (keine PAN-Verarbeitung).

8. Datenschutzprofil: „So wenig wie möglich“ vs. „so viel Komfort wie gewünscht“

Apple verfolgt den Grundsatz der Datenminimierung: Transaktionen sind für Apple nicht personenbezogen auswertbar; Karten existieren nicht in der iCloud als nutzbare PAN-Sätze; Tokens sind an ein Gerät gebunden. Diese Philosophie passt in viele Datenschutz-Governance-Modelle großer Unternehmen, die ein „Need-to-Know“ strikt leben.

Google bietet starke Privacy-Kontrollen, ist aber qua Plattform breiter vernetzt: Synchronisierte Zahlungsmittel, Chrome-Autofill, In-App-Käufe und weitere Google-Dienste können – sofern aktiviert – mehr Nutzungsmetadaten erzeugen. Wer das nicht möchte, kann (und sollte) umfangreiche Opt-Outs und Richtlinien nutzen. Die sichere Architektur (Tokenisierung, Kryptogramme, Attestation) bleibt davon unberührt; es geht hier um Datenökonomie, nicht um Zahlungssicherheit.

9. Häufige Fehlannahmen – und was wirklich stimmt

„Google Pay ist unsicher, weil es über Server läuft.“
Falsch pauschalisiert. Mit eSE ist der Schutzpfad vergleichbar mit Apple. HCE-Varianten ergänzen Server-Kontrolle, was nicht per se unsicher ist – sondern ein anderer Vertrauensanker. Kritisch ist die Geräteauswahl: Wer billigste Hardware zulässt, handelt sich eher Patch-/Attestierungsrisiken ein als Wallet-Risiken.

„Apple Pay sendet nie Daten übers Netz.“
Natürlich tun es beide – Zahlungen müssen schließlich autorisiert werden. Der Punkt ist: Apple überträgt keine PAN, speichert sie nicht, und der entscheidende Kryptogramm-Teil entsteht im SE. Die Netzwerke/Banken sehen das Nötige, Apple nicht mehr als nötig.

„Wallets machen PCI überflüssig.“
Sie reduzieren PCI-DSS-Last signifikant, weil keine PAN verarbeitet wird. Tot ist PCI damit nicht: Händler müssen Umgebungen absichern, Token schützen, Zugriffe steuern, Logging betreiben und Drittparteien auditieren.

10. Entscheidungshilfe für Sicherheitsverantwortliche

Wer iOS-Flotten betreibt oder BYOD vermeiden kann, erhält mit Apple Pay einen klaren, homogenen Sicherheitsanker: eSE überall, einheitliche Updatepolitik, starkes Privacy-Default.
Wer Android breit nutzen will oder muss, fährt mit Google Wallet/Pay ausgezeichnet – wenn die Flotte mindestens Mittelklasse-Geräte mit Android Ready SE nutzt, EMM/MDM konsequent Richtlinien durchsetzt, Play-Integrity-Signale prüft und Sicherheits-KPIs (Patch-Level-Quote, Bootloader-Lock, Biometrie-Abdeckung) überwacht.

Für beide Welten lohnt eine gemeinsame Grundlinie:

• Starke lokale Authentifizierung erzwingen (Biometrie + Code; keine „Pattern-Only“).
• Gerätezustand attestieren und unsichere Zustände blocken.
• Remote-Wipe/Wallet-Kill prozessual üben.
• Händler-Integrationen (Web/App) auf Token-Only trimmen; Klartext-PAN konsequent vermeiden.
• Mitarbeitende zu Wallet-Phishing und Gerätesperre sensibilisieren.

11. Fazit: Zwei sehr gute Wege – mit anderen Schwerpunkten

Apple Pay steht für maximale Hardwarebindung, strikte Datensparsamkeit und Plattform-Homogenität. Google Pay/Wallet steht für große Reichweite, Flexibilität und Konto-Komfort – bei sehr hoher Sicherheit, die je nach Geräteklasse über eSE oder HCE+Attestation bereitgestellt wird.

Die Prozessgrafik greift den Unterschied in der Ablage sensibler Informationen auf und macht ihn anschaulich – sie vereinfacht allerdings die Vielfalt moderner Android-Implementierungen. Entscheidend ist am Ende nicht die Marke, sondern die gelebte Umsetzung:

• Wie werden Geräte ausgewählt, gepflegt und attestiert?
• Wie strikt ist die lokale Authentifizierung?
• Wie gut ist die Integration beim Händler, damit niemals PAN anfallen?
• Wie sauber sind Datenschutz-Defaults und Unternehmensrichtlinien gesetzt?

Wer diese Fragen strukturiert beantwortet, bekommt mit beiden Wallets ein Sicherheitsniveau, das klassische Kartenzahlungen deutlich übertrifft. In Zeiten allgegenwärtiger Datenlecks ist das kein kleines Versprechen, sondern ein sehr greifbarer Fortschritt – und wahrscheinlich der Hauptgrund, warum mobile Wallets in vielen Risikobewertungen heute die bevorzugte Zahlart sind.