Zahlen mit einem Fingerabdruck

Apple Pay: Wie funktioniert es und: Wie sicher ist es?
Kommentare

Apple hat mit Apple Pay ein neues Zahlungssystem vorgestellt, das einige Probleme lösen könnte. Vor allem die in den USA zu einem großen Problem gewordenen Angriffe auf die Kreditkartendaten im Point of Sale sind bei Apple Pay zwar nicht unmöglich, aber zwecklos.

Am 9. September 2014 hat Apple zusammen mit der Präsentation von iPhone 6 und iPhone 6Plus sein Bezahlsystem Apple Pay vorgestellt. Eingeführt wurde Apple Pay zunächst in den USA. Neun Monate später, am 14. Juli 2015, war es dann auch in Europa so weit und Apple Pay ging in Großbritannien an den Start – in mehr als 250.000 Läden, Restaurants, Tankstellen, Postämtern und im öffentlichen Nahverkehr.

Die folgende Beschreibung basiert auf den von Apple veröffentlichten Informationen auf der Website, in einem Supportdokument, und im iOS Security Guide, Ausgabe Oktober 2014. Die Beschreibung ist in drei Teile aufgeteilt: Zuerst lernen Sie die beteiligten Komponenten kennen. Danach folgt das Aktivieren von Apple Pay und zu guter Letzt die Zahlung in einem Geschäft. Die ebenfalls mögliche Nutzung zur Zahlung in Apps ist im Kasten beschrieben. Abschließend geht es um die Frage, wie sicher das alles ist.

Die Bezahlung innerhalb von Apps

Bezahlungen innerhalb von Apps werden über den Apple-Pay-Server abgewickelt. Apple Pay speichert dabei anonyme Transaktionsinformationen wie den ungefähren Zahlungsbetrag. Diese Informationen können nicht zum Benutzer zurückverfolgt werden und enthalten keine Informationen darüber, was der Benutzer gekauft hat. Die Abwicklung der Zahlungen erfolgt über ein API und erfordert die Angabe einer Händler-ID (Merchant-ID), die den Händler hinter der App eindeutig identifiziert, und die in die Zahlungsinformationen übernommen wird.

Der Beginn der Zahlung

Erfordert eine App eine Zahlung, prüft sie zuerst über das API, ob das iPhone Apple Pay unterstützt, ob es aktiviert ist und ob der dafür verwendete Zahlungsdienstleister vom Händler akzeptiert wird. Ist eine Zahlung möglich, stellt die App die dafür nötigen Informationen, wie zum Beispiel Rechnungs- und Lieferadressen und Kontaktinformationen, zusammen. Danach fordert die App iOS zur Anzeige des Apple-Pay-Dialogs auf, der alle relevanten Informationen zur Zahlung anzeigt.

Stimmt der Benutzer der Zahlung durch die Touch-ID oder die Eingabe des Passcodes zu, werden alle im Apple-Pay-Dialog angezeigten Informationen dem Händler mitgeteilt.

Die eigentliche Zahlung

Nachdem der Benutzer die Zahlung autorisiert hat, wird vom Apple-Pay-Server ein kryptografischer Nonce-Wert angefordert, der dem bei der Zahlung im Geschäft vom NFC-Terminal des Händlers gelieferten Nonce entspricht. Wie bei der Zahlung im Geschäft werden dann alle benötigten Informationen vom Secure Element zusammengefasst und mit dem Schlüssel der Apple-Pay-Server verschlüsselt. Danach werden die Daten an den Apple-Pay-Server gesendet, der sie entschlüsselt, den Nonce prüft und die Daten im Erfolgsfall mit dem zur Händler-ID gehörenden Händler-Schlüssel verschlüsselt.

Die neu verschlüsselten Zahlungsinformationen werden dann zurück an das iPhone geschickt, das sie über das Apple-Pay-API an die App weiterleitet. Die App wiederum leitet die Daten an den Server des Händlers weiter, der sie entschlüsselt und weiterverarbeitet. Wie im Fall einer Zahlung im Geschäft kann dafür wieder auf die vorhandene Infrastruktur zur Zahlung mit Kreditkarten zurückgegriffen werden.

Schutz zusätzlicher Daten

Außer den Zahlungsinformationen muss die App im Allgemeinen weitere Informationen wie zum Beispiel Bestellnummern oder eine Kundennummer an den Händler schicken. Um diese Daten vor Manipulationen zu schützen, kann die App sie über das API vom Secure Element signieren lassen.

Ein Hash dieser Daten wird den verschlüsselten Zahlungsinformationen beigefügt. Der Händler kann also bei Bedarf prüfen, ob die ihm von der App gelieferten Daten unversehrt sind.

Machen wir es uns einfach(er) …

Apple Pay in allen Aspekten zu beschreiben, würde den Rahmen des Artikels schnell sprengen. Daher sind einige Vereinfachungen nötig.

Zur Aktivierung von Apple Pay wird entweder eine im iTunes Store registrierte Kreditkarte zum Passbook hinzugefügt oder die Daten einer neuen Kreditkarte entweder eingetippt oder die Karte einfach mit dem iPhone fotografiert. In der Beschreibung gehe ich vom Fotografieren der Karte aus, da dabei die meisten Daten anfallen.

Wenn ich bei der Beschreibung der Zahlung in Geschäften iPhone schreibe, meine ich damit auch nur das iPhone, denn bisher funktioniert diese Zahlung mit Apple Pay nur mit dem iPhone 6 und 6 Plus. Die Apple Watch gibt es ja noch nicht, und bis sie erscheint, kann es durchaus noch zu Änderungen an den bisher geplanten Funktionen und Abläufen kommen.

Im Fall der Zahlung innerhalb von Apps gilt das Beschriebene aber analog für iPad Air 2 und iPad mini 3, auch wenn ich dort der Einfachheit halber weiter nur iPhone schreibe.

Und wenn ich Bank schreibe, ist damit ebenso der jeweilige Zahlungsdienstleister, wie zum Beispiel das Kreditkartenunternehmen gemeint, sofern es einen gibt.

1. Die Komponenten von Apple Pay

Im iPhone sind mehrere Komponenten für die Funktion und Sicherheit von Apple Pay unverzichtbar. Fangen wir mit der Hardware an, die auch in Abbildung 1 dargestellt ist:

Das Secure Element

Das Secure Element ist ein Industriestandard zur sicheren Speicherung und Verwaltung sensitiver Daten. In einem zertifizierten Mikrocontroller läuft die den Anforderungen der Finanzindustrie für elektronische Zahlungen entsprechende Java-Card-Plattform. Im Fall von Apple Pay laufen darauf Applets zur Verwaltung von Apple Pay sowie von den Zahlungsdienstleistern zertifizierte Zahlungs-Applets. Die für die Zahlung benötigten Daten werden vom Kreditkartenunternehmen oder der ausgebenden Bank mit nur ihnen und dem Payment Applet bekannten Schlüsseln verschlüsselt an das Applet im Secure Element gesendet. Dort werden sie vom Applet verwaltet und durch die Schutzmaßnahmen des Secure Elements geschützt.

Der NFC-Controller

Der NFC-Controller ist zum einen für die Kommunikation des iPhones mit dem Point-of-Sale-Terminal im Geschäft über die Protokolle der Near Field Communication zuständig. Während einer Transaktion kommuniziert das Terminal im Geschäft über den NFC-Controller direkt mit dem Secure Element. NFC-Controller und Secure Element sind über einen eigenen Hardwarebus direkt miteinander verbunden, sodass iOS keinen Zugriff auf die übertragenen Daten hat.

Zum anderen wickelt der NFC-Controller bei der Zahlung innerhalb einer App die Kommunikation zwischen der App und dem Secure Element ab.

Die Secure Enclave

Die Secure Enclave ist ein besonders geschützter Bereich innerhalb des iPhone-Prozessors und verwaltet generell jeden Authentifizierungsprozess auf dem iPhone. In ihr sind zum Beispiel auch die Fingerabdruckdaten für die Touch-ID gespeichert. Sie ist im Fall von Apple Pay für die Autorisierung einer Zahlungstransaktion zuständig. Erst nachdem der Benutzer einer Transaktion durch die Touch-ID oder die Eingabe des Passcodes zugestimmt hat, wird die Abwicklung der Zahlung angestoßen und die Kontrolle an NFC-Controller und Secure Element übergeben.

Die Verbindung von Secure Enclave und Secure Element

Secure Enclave und Secure Element kommunizieren über ein serielles Interface; das Secure Element ist zusätzlich mit dem NFC-Controller verbunden, der seinerseits mit dem Anwendungsprozessor verbunden ist.

Secure Enclave und Secure Element können auch ohne direkte Verbindung sicher miteinander kommunizieren, da die Verbindung mit einem während des Herstellungsprozesses installierten gemeinsamen Pairing-Schlüssel verschlüsselt wird. Dieser Schlüssel wird vom Secure Element aus dem UID-Schlüssel und dem eindeutigen Identifier des Secure Elements berechnet und in der Fabrik auf sicherem Wege in ein Hardware Security Module (HSM) übertragen, von wo aus es dann in die Secure Enclave übertragen wird. Verschlüsselung und Authentifizierung basieren auf AES, wobei auf beiden Seiten kryptografische Nonces zum Schutz vor Replay-Angriffen zum Einsatz kommen.

Abb. 1: Die beteiligten Komponenten im iPhone

Abb. 1: Die beteiligten Komponenten im iPhone

Der „Authorization Random“-(AR-)Wert

Kein Teil der Hardware, sondern eine wichtige Konstante ist der „Authorization Random“-(AR-)Wert. Er wird in der Secure Enclave erzeugt, wenn der Benutzer eine Kreditkarte erstmals nutzt, und ist persistent, so lange Apple Pay aktiviert ist. Wenn er an das Secure Element gesendet wird, wird er mit dem Pairing-Schlüssel verschlüsselt; in der Secure Enclave wird er von deren Verschlüsselungs- und Anti-Rollback-Mechanismen vor dem Ausspähen geschützt. Empfängt das Secure Element einen neuen AR, werden alle zuvor hinzugefügten Karten als gelöscht markiert.

Zum Secure Element hinzugefügte Kreditkarten können nur verwendet werden, wenn das Secure Element dazu mit dem gleichen Pairing-Schlüssel und AR autorisiert wird, die beim Hinzufügen der Karte verwendet wurden. Dies ermöglicht es iOS, die Karten von der Secure Enclave unbrauchbar machen zu lassen, indem der AR als ungültig markiert wird. Das ist nötig, wenn

  • der Passcode ausgeschaltet wird
  • der Benutzer sich aus der iCloud ausloggt
  • der Benutzer alle Inhalte und Einstellungen löscht
  • das iOS-Gerät im Recovery-Modus wiederhergestellt wird

Apple Pay kommt natürlich nicht ohne Software aus. Außer den schon erwähnten Apps der verschiedenen Zahlungsdienstleister im Secure Element ist dies die Passbook-App.

Die Passbook-App

Im Rahmen von Apple Pay übernimmt Passbook das Hinzufügen und die Verwaltung der Kreditkarten sowie die Ausführung von Zahlungen. Der Benutzer kann in Passbook zum Beispiel seine Kreditkartendaten und zusätzliche Informationen wie die Geschäftsbedingungen und Datenschutzbestimmungen seiner Bank oder die letzten Zahlungen betrachten, neue Kreditkarten zu Apple Pay hinzufügen oder Zahlungen in Geschäften oder Apps durchführen.

Außer dem iPhone und der darauf laufenden Software sind auch Server an der Funktion von Apple Pay beteiligt.

Der Apple-Pay-Server

Der Apple-Pay-Server verwaltet den Status der in Passbook aktivierten Kreditkarten sowie der im Secure Element gespeicherten Device Account Numbers (siehe unten). Der Apple-Pay-Server kommuniziert sowohl mit dem iPhone als auch den Servern der Banken und vermittelt zwischen beiden. Außerdem ist er für die Umverschlüsselung der Zahlungsdaten für Zahlungen innerhalb von Apps zuständig.

Die Bank-Server

Die Bank-Server erfüllen zwei Aufgaben: Zum einen sind sie für die Freigabe der Kreditkarten für Apple Pay zuständig. Eine neue Kreditkarte kann erst dann mit Apple Pay verwendet werden, wenn dies von der ausstellenden Bank genehmigt wurde. Zum anderen wickeln sie natürlich die Zahlungen ab.

Bei der Durchführung von Zahlungen in Geschäften wird auf der Händlerseite die vorhandene Infrastruktur zur Abwicklung von Kreditkartenzahlungen verwendet. Die Daten werden also darüber an den Bank-Server geschickt, der die Zahlung dann durchführt (oder bei einem Missbrauch verweigert). Dabei kommen im Prinzip die gleichen Verfahren wie für Kreditkartenzahlungen zum Einsatz, nur, dass der Auftraggeber nicht über seine Kreditkartendaten, sondern Apple Pay identifiziert wird.

2. Apple Pay aktivieren

Zur Kommunikation mit der Bank verwendet Apple Pay zwei serverseitige Aufrufe: „Check Card“ und „Link and Provision“. Die Bank kann darüber Karten prüfen, genehmigen und zu Apple Pay hinzufügen. Die Kommunikation wird dabei über SSL verschlüsselt.

Zur Aktivierung von Apple Pay wird die Karte einfach mit dem iPhone fotografiert. Die Passbook-App versucht dann, den Namen, die Kartennummer und das Ablaufdatum zu erfassen. Das Foto wird weder auf dem Gerät gesichert noch zum Fotoalbum hinzugefügt. Sind alle Felder ausgefüllt, prüft der „Check-Card“-Prozess die Kartennummer und das Ablaufdatum, die dann verschlüsselt an den Apple-Pay-Server gesendet werden.

Der „Check-Card“-Prozess kann dann eine „Terms-and-Conditions“-ID zurückliefern, woraufhin die Passbook-App die zugehörigen Nutzungsbedingungen lädt und dem Benutzer anzeigt. Akzeptiert dieser die Bedingungen, wird die ID der akzeptierten Bedingungen zusammen mit dem vom Benutzer abgefragten Card Verification Value (CVV, der Sicherungscode der Kreditkarte, der vom Benutzer bei der Onlinenutzung eingegeben werden muss, um zu beweisen, dass er die Karte wirklich vorliegen hat) an den „Link-and-Provision“-Prozess gesendet. Der erhält zusätzlich einige Informationen über das Gerät wie die letzten vier Ziffern der Telefonnummer, den Devicenamen und den aktuellen Standort des Geräts, aufgerundet auf ganze Zahlen.

Die gesammelten Daten werden vom „Link-and-Provision“-Prozess verschlüsselt an die Bank gesendet, die auf Grundlage dieser Informationen entscheidet, ob die Kreditkarte für Apple Pay verwendet werden darf. Wenn ein Bankkunde sich zum Beispiel normalerweise nur innerhalb der USA aufhält und sich während eines Russlandurlaubs und womöglich noch mit einem neu gekauften iPhone zur Aktivierung von Apple Pay entschließt, könnte die Aktivierung an dieser Prüfung scheitern.

Der „Link-and-Provision“-Prozess endet mit dem Download der die Kreditkarte repräsentierenden Passbook-Pass-Datei auf dem Gerät sowie dem Binden der Karte an das Secure Element.

Die Pass-Datei beinhaltet den URL zum Herunterladen eines Kartenbilds und Metadaten wie Kontaktinformationen, die zugehörige Bank-App und unterstützte Features der Karte. Außerdem enthält sie ein Statusfeld, das Informationen darüber enthält, ob die Personalisierung des Secure Elements abgeschlossen wurde, die Karte aktuell vom Herausgeber gesperrt ist oder ob vor der Nutzung der Karte durch Apple Pay eine zusätzliche Verifizierung, zum Beispiel durch eine Textnachricht, eine E-Mail, einen Anruf oder Ähnliches, erforderlich ist. Der Ablauf der Aktivierung ist in Abbildung 2 zusammengefasst.

Die Device Account Number

Erteilt die Bank ihre Zustimmung zur Nutzung der Karte, erzeugt sie eine eindeutige, gerätespezifische Device Account Number, die verschlüsselt und zusammen mit weiteren Daten wie dem Schlüssel zur Erzeugung transaktionsspezifischer Sicherheitscodes im Secure Element auf dem iPhone gespeichert werden.

Die Device Account Number ist eindeutig und mit dem iPhone und der Kreditkarte verknüpft, identifiziert also den Auftraggeber einer Zahlung eindeutig. Sie ist von iOS isoliert und wird niemals auf dem Apple-Pay-Server oder in iCloud-Backups gespeichert. Apple speichert auch die Kreditkartendaten nicht und hat auch keinen Zugriff auf die auf dem Gerät gespeicherten Daten.

Um die Verwaltung der Karten durch den Benutzer zu ermöglichen (irgendwie muss der ja ggf. aus mehreren für Apple Pay genutzten Kreditkarten die aktuell gewünschte auswählen können), speichert Apple Pay allerdings Teile der Kreditkartennummer und der Device Account Number zusammen mit einer Beschreibung.

Abb. 2: Die Aktivierung von Apple Pay im Überblick

Abb. 2: Die Aktivierung von Apple Pay im Überblick

Das Löschen von Kreditkarten

Der Benutzer hat mehrere Möglichkeiten, die für Apple Pay aktivierten Kreditkarten zu löschen. Zum einen geht das direkt über Passbook, zum anderen Remote über Find My iPhone oder die iCloud-Einstellungen. Wird über Find My iPhone der „Lost Mode“ aktiviert, wird Apple Pay deaktiviert.

Außerdem besteht zusätzlich die Möglichkeit, das gesamte iPhone über die Funktion „Alle Daten und Einstellungen löschen“ oder Find My iPhone zu löschen. Dann wird das Secure Element angewiesen, alle Karten als gelöscht zu markieren, sodass sie nicht mehr benutzt werden können. Beim nächsten Kontakt mit dem Apple-Pay-Server werden die Kreditkarten dann aus dem Secure Element gelöscht. Unabhängig davon markiert die Secure Enclave den AR als ungültig, sodass für die damit installierten Kreditkarten keine Zahlungen mehr autorisiert werden können. Das Gleiche passiert, wenn ein iPhone im Recovery-Mode wiederhergestellt wird.

3. Die Bezahlung im Geschäft

Bei der Bezahlung im Geschäft kommuniziert das Terminal des Händlers über NFC mit dem davor gehaltenen iPhone, das daraufhin die Default-Kreditkarte und den zu zahlenden Betrag anzeigt. Die Zahlung erfolgt nur, wenn der Benutzer sie über die Touch-ID (die Default-Methode) oder die Eingabe des Passcodes bestätigt hat.

Der Passcode kann unabhängig von der Default-Methode immer verwendet werden. In bestimmten Situationen ist er zwingend erforderlich, z. B. wenn Touch-ID nicht konfiguriert oder nicht für Apple Pay aktiviert ist, oder nach fünf fehlgeschlagenen Versuchen mit der Touch-ID. Bereits nach drei Fehlversuchen mit der Touch-ID wird die Eingabe des Passcodes vorgeschlagen, aber noch nicht erzwungen.

Nachdem der Benutzer der Zahlung zugestimmt hat, werden von der Secure Enclave zur Autorisierung Daten über die Art der Authentifizierung und Details über den Typ der Transaktion (in diesem Fall „kontaktlos“ im Gegensatz zur Nutzung innerhalb von Apps), gebunden an den „Authorization Random“-(AR-)Wert, signiert an das Secure Element gesendet. Das Secure Element prüft mit dem Pairing-Schlüssel und seiner Kopie des aktuellen AR, ob die von der Secure Enclave gesendete Autorisierung korrekt ist. Erst wenn diese Prüfung erfolgreich war, wird das Payment Applet für die kontaktlose Zahlung aktiviert.

Das Payment Applet erzeugt nun einen transaktionsspezifischen Sicherheitscode, der ebenso wie die Device Account Number Bestandteil jeder Zahlung ist. Für die Berechnung dieses nur jeweils einmal gültigen Codes wird der dazu während der Aktivierung der Kreditkarte im Payment Applet hinterlegte Schlüssel verwendet, der außer dem Applet nur der Bank bekannt ist. In die Berechnung gehen unter anderem die folgenden Daten ein:

  • ein mit jeder neuen Transaktion inkrementierter Zähler
  • eine vom Payment Applet erzeugte Zufallszahl
  • eine vom NFC-Terminal erzeugte Zufallszahl

Der Sicherheitscode, die Device Account Number und alle weiteren für die Zahlung benötigten Daten werden dann über NFC an das Händlerterminal gesendet. Von da aus geht die Zahlung den normalen Weg einer Kreditkartenzahlung, nur eben ohne dass dabei die Kreditkartendaten übertragen werden.

Die Bank kann mithilfe der Device Account Number den Auftraggeber identifizieren und mithilfe des Sicherheitscodes die Zahlungen verifizieren. Der Code muss zum angegebenen Gerät gehören und eindeutig sein. Ein Replay-Angriff, bei dem aufgezeichnete Transaktionen erneut gesendet werden, ist also nicht möglich. Den Ablauf der Zahlung im Überblick sehen Sie in Abbildung 3.

Abb. 3: Die Zahlung im Geschäft im Überblick

Abb. 3: Die Zahlung im Geschäft im Überblick

Welche Daten erhält Apple?

Ein Teil der übertragenen Daten wurde ja oben bereits aufgeführt. Ein Überblick ist aber trotzdem angebracht. Apple erhält bei der Nutzung von Apple Pay die folgenden Daten (oder in manchen Fällen auch explizit nicht), die aber laut Apple nicht alle gespeichert werden:

  1. Beim Aktivieren einer Kreditkarte
  • beim Hinzufügen einer Kreditkarte über ein Foto wird das Bild nur lokal auf dem iPhone ausgewertet und weder an den Apple-Pay-Server gesendet noch im Fotoalbum oder sonst wo auf dem Gerät gespeichert.
  • Die Kreditkartendaten werden nur an den Bank-Server weitergeleitet, aber weder auf dem Apple-Pay-Server noch auf dem iPhone gespeichert.
  • Die Device Account Number wird im Secure Element gespeichert, wo sie von iOS isoliert ist. Sie wird daher auch nicht im iCloud-Backup gespeichert. Apple erfährt sie im Rahmen der Zahlung innerhalb von Apps, speichert sie aber nicht.
  1. Bei der Bezahlung im Geschäft
  • Die Zahlung wird zwischen iPhone und NFC-Terminal des Händlers abgewickelt; der Apple-Pay-Server ist nicht involviert.
  • Datum und Uhrzeit der Nutzung sowie der Standort (sofern die Ortungsdienste eingeschaltet sind) werden in anonymer Form an den Apple-Pay-Server gesendet. Wie üblich, um mit diesen Daten Apple Pay zu verbessern.
  1. Bei der Bezahlung innerhalb einer App
  • Da der Apple-Pay-Server die Zahlungsinformationen neu verschlüsselt, kann Apple alle darin enthaltenen Informationen wie die Device Account Nummer und den Zahlbetrag lesen. Diese Daten werden aber nicht ausgewertet.

Kommen wir nun zur Sicherheit, angefangen beim:

Schutz der Kreditkartendaten …

Die Kreditkartendaten könnten an mehreren Stellen ausgespäht werden: Im iPhone, auf den Servern von Apple Pay, Händler und Bank sowie während der Übertragung zwischen diesen Stellen. Betrachten wir mal die verschiedenen Möglichkeiten genauer.

… während der Aktivierung

Im Rahmen der Aktivierung von Apple Pay sind die Kreditkartendaten der größten Gefahr ausgesetzt, da sie sowohl auf dem iPhone vorliegen als auch über das Netz übertragen werden. Auf dem iPhone könnten die Daten dabei von eingeschleuster Schadsoftware ausgespäht werden, die es bisher bis auf eine Ausnahme allerdings nur auf Geräten mit Jailbreak gibt [1].

Bei der Installation eines Jailbreaks verzichtet der Benutzer bewusst auf sämtliche vorhandenen Schutzmaßnahmen und ist für die Folgen ganz allein verantwortlich. Die erwähnte Ausnahme ist der über Enterprise-Zertifikate im Rahmen des WireLurker-Angriffs auf iOS-Geräten ohne Jailbreak installierte Schädling. Und der wird nur aktiv, wenn der Benutzer es explizit erlaubt, womit er wiederum selbst Schuld ist.

Hinzu kommt, dass die eingeschleuste Schadsoftware dann auch noch Zugriff auf die Sandbox mit der Passbook-App erhalten muss, um an die davon verarbeiteten Daten zu gelangen. Oder auf den Speicher der iPhone-Kamera, um dort das Bild der Kreditkarte auszuspähen – beides keine trivialen Vorgänge. Ich denke daher, diese Gefahr kann man bis zum Auftauchen neuer Angriffe oder Schwachstellen ignorieren.

Kommen wir zur Übertragung der Kreditkartendaten. Da diese über SSL geschützt wird, sind hier die üblichen Angriffe, zum Beispiel durch einen Man in the Middle oder einen kompromittierten Server, möglich. Allerdings sind sie genauso möglich, wenn die Kreditkartendaten beim herkömmlichen Einsatz der Karte zum Bezahlen in Onlineshops etc. übertragen werden. Insofern gibt es also keine wirklich neuen Gefahren, ganz im Gegenteil: Bei Apple Pay werden die Kreditkarten nur während der Aktivierung übertragen, danach nie wieder. Zudem werden sie nur an die Apple-Pay- und Bank-Server gesendet, nicht an etliche Händlerserver. Insgesamt gibt es also sehr viel weniger Gelegenheiten für einen Angriff.

… bei der Zahlung

Die größte Gefahr beim Bezahlen mit Kreditkarte besteht darin, dass die Kartendaten ausgespäht und missbraucht werden. Selbst wenn dem Benutzer der entstehende Schaden ersetzt wird, hat er durch den Missbrauch jede Menge Ärger.

In den USA ist diese Gefahr seit einiger Zeit besonders akut, da es inzwischen für den Angriff auf den Point of Sale spezialisierte Schadsoftware gibt [2]. Die hat nur zwei Aufgaben: Den Point of Sale möglichst lange unbemerkt zu kompromittieren und alle darüber laufenden Kreditkartendaten an die Cyberkriminellen zu schicken. Und das hat bereits einige Male im erschreckend großen Ausmaß geklappt.

In Deutschland sind solche Angriffe noch nicht vorgekommen, da hier eher selten mit der Kreditkarte bezahlt wird. Aber auch die deutlich öfter genutzten Bankkarten sind nicht ungefährdet; es gab bereits Angriffe über manipulierte Kartenleser.

Vor diesen Angriffen ist die Nutzung von Apple Pay ein effektiver Schutz: Da die Kreditkartendaten nicht übertragen werden, können sie nicht ausgespäht werden. Und wenn die Cyberkriminellen die stattdessen verwendete Device Account Number ausspähen, haben sie nichts davon, denn jede Transaktion muss mit dem transaktionsspezifischen Sicherheitscode autorisiert werden. Den ebenfalls ausgespähten Wert können die Cyberkriminellen nicht erneut verwenden, und einen neuen können sie nicht erstellen, da der mithilfe eines nur dem iPhone und der Bank bekannten Schlüssels erzeugt wird.

Das Gleiche gilt analog für einen Angriff auf die Zahlung innerhalb von Apps: Sollten die Cyberkriminellen den Server des Händlers kompromittieren, finden sie dort wie schon im Fall des Point of Sale keine für die Durchführung unbefugter Zahlungen nutzbaren Daten.

Allgemein wird der Ersatz der Kreditkartendaten durch einen anderen Wert als „Tokenization“ bezeichnet, der Ersatzwert dementsprechend auch als Token. Die Kreditkartenunternehmen arbeiten schon seit einiger Zeit an der Entwicklung eigener Lösungen, Apple war aber schneller fertig und liefert zusätzlich noch eine universelle Lösung.

… auf iPhone und Servern

Die Kreditkartendaten werden beim Einsatz von Apple Pay weder im iPhone noch auf dem Apple-Pay-Server gespeichert. Bei Apple sind die Daten allerdings gespeichert; wenn der Benutzer seine Kreditkarte für die Bezahlung in iTunes, App oder Mac App Store verwendet, wird sie ja für die Abwicklung der Zahlungen benötigt.

Die Bank-Server kennen die Kreditkartendaten sowieso, hier kommt also beim Einsatz von Apple Pay kein neuer Angriffspunkt dazu.

Im Fall der Händler fällt sogar ein Angriffspunkt weg: Während diese die Kreditkartendaten bei der Zahlung mit Kreditkarte speichern müssen, erfahren sie dies bei der Nutzung von Apple Pay gar nicht erst.

Missbrauch von Apple Pay

Kann Apple Pay missbraucht werden? Bei vielen anderen kontaktlosen Zahlungsmöglichkeiten, wie zum Beispiel den RFID-basierten Bankkarten, erfolgt die Zahlung ohne Interaktion des Benutzers, wenn die Karte nah genug an den RFID-Leser des Geschäfts gebracht wird. Im Gegensatz dazu muss der Benutzer der Zahlung bei Apple Pay explizit zustimmen.

Betrachten wir die beiden möglichen Angriffe:

Erstens: Der Einsatz eines bösartigen Lesegeräts, mit dem ein Krimineller die Geldkarten aller nah genug herankommenden Personen leert. Im November 2014 wurde für die in Großbritannien üblichen RFID-basierten Karten sogar gezeigt, wie das dort geltende Limit von 20 Pfund durch Abbuchungen in einer anderen Währung teilweise umgangen werden kann. Ein derartiger Angriff scheitert bei Apple Pay an der nötigen Autorisierung der Zahlung durch den Benutzer. Zweitens: Der Missbrauch einer gestohlenen Karte bzw. eines gestohlenen iPhones. Eine ohne Authentifizierung arbeitende Karte könnte bis zum Verbrauch des vorhandenen Guthabens missbraucht werden. Aber ob nun ein Portemonnaie mit 20 Euro Bargeld oder die mit 20 Euro geladene Geldkarte gestohlen wird, ist in der Hinsicht völlig egal.

Womit wir zum möglichen Missbrauch eines gestohlenen iPhones kommen. Erstmal muss für die Nutzung von Apple Pay die Touch-ID oder der Passcode aktiviert sein; der Dieb müsste sich also erst mal Zugriff auf das Gerät beschaffen, bevor er Apple Pay missbrauchen kann. Sollte er aber den Passcode kennen oder ermitteln oder die Touch-ID überlisten, würde er nicht nur Zugriff auf das iPhone erlangen, sondern könnte auch Apple Pay nutzen.

Dass die Touch-ID nicht unüberwindbar ist, wurde schon kurz nach der Vorstellung der neuen Geräte demonstriert. Das war auch im Fall des iPhone 6 nicht anders (Text / Video), hier sogar mit einer Fingerattrappe, die schon am iPhone 5 funktioniert hat. Der Angreifer muss aber einen sehr guten Fingerabdruck des Benutzers haben, um ihn als Ausgangspunkt seiner Attrappe zu verwenden. Und an den muss er erst mal dran kommen. Die verwischten Reste auf einem gestohlenen iPhone werden in den meisten Fällen ungeeignet sein.

Für einen Gelegenheitsdieb dürfte der Aufwand für einen Angriff also zu groß sein, und für die organisierteren Kriminellen ist er zu klein. Diese denken in großen Maßstäben und spähen massenhaft Kreditkartendaten aus, die dann auf Blankokarten geschrieben und in irgendeinem anderen Land genutzt werden, um an Geldautomaten Geld abzuheben. Einzelne iPhones, die noch dazu leicht aus der Ferne gelöscht werden können, sind für sie viel zu kleine Fische.

Angriffe über NFC

Wie sicher ist die Kommunikation über NFC? Bereits 2012 wurde der Ecardgrabber für Android entwickelt, der über NFC übertragene Kreditkartendaten ausspähen kann, wenn das Android-Gerät bis auf wenige Zentimeter an das NFC-Terminal oder das damit kommunizierende Smartphone herankommt. 2013 hat ein Forscher rund 90 cm mittels NFC überbrückt. Das erleichtert Angriffe auf Systeme, bei denen Zahlungen ohne Interaktion des Benutzers möglich sind, bringt den Angreifer im Fall von Apple Pay aber auch nicht näher an sein Ziel. Denn Apple Pay führt die Zahlung ja nur aus, wenn der Benutzer sie autorisiert. Aus welcher Entfernung die Transaktion ausgelöst wurde, ist dabei völlig egal. Und auch das Ausspähen übertragener Daten ist für Apple Pay kein Problem. Wie bereits oben beschrieben, sind die ausspähbaren Daten für die Kriminellen wertlos. Ein anderes Problem sind Angriffe über NFC, die Schwachstellen im Treiber des Controllers oder der sonstigen darüber erreichbaren Software ausnutzen. Charlie Miller warnte zum Beispiel auf der Black Hat USA 2012 „Don’t Stand So Close To Me“ und veröffentlichte eine Analyse der Angriffsfläche von NFC. Und beim Pwn2Own-Mobile-Wettbewerb 2014 wurde über NFC zwei Mal das Samsung Galaxy S5 und einmal das LG Nexus 5 erfolgreich kompromittiert. Für das iPhone waren Angriffe über NFC diesmal noch kein Thema, da nur das iPhone 5 als Ziel zur Verfügung stand. NFC wurde ja erst mit dem iPhone 6 eingeführt, und das und iOS müssen im nächsten Jahr erst mal beweisen, dass sie Angriffen besser widerstehen als die Konkurrenzprodukte.

Allerdings gibt es für die Angreifer dabei noch eine weitere mögliche Hürde zu meistern: Zumindest bisher ist NFC im iPhone ausschließlich Apple Pay vorbehalten. Die Angriffsfläche ist also deutlich geringer, als bei Geräten, die über NFC viele verschiedene Dienste zugänglich machen, damit aber natürlich auch viel interessanter.

Aber selbst wenn Angriffe entwickelt werden, bedeutet das nicht, dass sie auch „in the Wild“ vorkommen, denn dabei darf man das „N“ in NFC nicht unterschätzen. Ein Krimineller muss im Allgemeinen ziemlich nah an sein Opfer heran, bevor er einen Angriff über NFC starten kann. Oder er müsste ein Händlerterminal kompromittieren und so präparieren, dass es die iPhones während der Nutzung angreift. Das ist zwar nicht unmöglich, aber mit einigem Aufwand verbunden. Angriffe über NFC schätze ich daher zwar als prinzipiell möglich ein, halte sie „in the Wild“ aber für sehr unwahrscheinlich.

Fazit

Apple Pay ist eine sehr gut durchdachte Lösung, die vor allem mit dem Problem der ausgespähten Kreditkartendaten in den USA Schluss machen kann. Aus Sicherheitssicht ist nichts daran auszusetzen; wie es mit dem Datenschutz aussieht, bleibt abzuwarten. Nur weil Apple sagt, man speichert fast nichts, muss das ja nicht zwingend so bleiben. Aber in der Hinsicht ist bei der Bezahlung im Geschäft sowieso Bargeld die einzige wirklich sichere Lösung, denn nur damit kann anonym gezahlt werden. Online hinterlässt eine Zahlung immer Spuren, die Frage ist nur, wo und wie viele. Und Apples Lösung scheint schon recht sparsam mit den gespeicherten Daten umzugehen.

Links & Literatur

[1] Eilers, Carsten: „Sicher, sicherer, iOS?“, in Mobile Technology 4.2012
[2] Eilers, Carsten: „Exotisches Ungeziefer“, in Windows Developer 11.2014

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -