SECURE ELEMENTS AM BEISPIEL GOOGLE WALLET

Transkript

1 Zentrum für sichere Informationstechnologie Austria Secure Information Technology Center Austria A-1030 Wien, Seidlgasse 22 / 9 Tel.: (+43 1) Fax: (+43 1) A-8010 Graz, Inffeldgasse 16a Tel.: ( ) Fax: ( ) office@a-sit.at DVR: ZVR: UID: ATU SECURE ELEMENTS AM BEISPIEL GOOGLE WALLET VERSION THOMAS ZEFFERER THOMAS.ZEFFERER@A-SIT.AT Zusammenfassung: Die zunehmende Popularität von Smartphones und die Integration neuer Technologien in diese Geräte eröffnen neue Möglichkeiten für die Umsetzung mobiler Bezahlsysteme. Mobile Bezahlsysteme erlauben Benutzerinnen und Benutzern die Durchführung von Bezahlvorgängen unter Verwendung eines mobilen Endgeräts. Eine häufige Ausprägung mobiler Bezahlsysteme ist die Verwendung eines Smartphones als virtuelle Geldbörse. Mit Google Wallet wurde erst im Jahr 2011 ein derartiger Dienst in den Vereinigten Staaten landesweit gestartet. Google Wallet ermöglicht die Virtualisierung von Kreditkarten in Smartphones und erlaubt die Durchführung von Kreditkartenzahlungen in Geschäften, die mit entsprechenden Terminals ausgestattet sind. Google Wallet ist bisher nur für Googles Android Smartphone- Plattform verfügbar. Die Kommunikation zwischen Terminal und Smartphone beruht auf der NFC-Technologie. Diese ermöglicht eine einfache kontaktlose Übertragung von Daten und erlaubt damit die Reduzierung des Bezahlvorgangs auf ein Berühren des Terminals mit dem NFC-fähigen Smartphone (Tap & Go ). Diese Form der Bezahlung ist vor allem in den Vereinigten Staaten durch das MasterCard PayPass -Verfahren bereits einigermaßen etabliert. Während bei diesem jedoch entsprechende Kreditkarten direkt kontaktlos ausgelesen werden, beruht Google Wallet auf Smartphones als Träger der virtuellen Kreditkarten. Da Smartphones als potentiell unsichere Umgebung eingestuft werden müssen, bedürfen die auf einem Smartphone gespeicherten virtuellen Kreditkarten eines speziellen Schutzes. Zur lokalen Speicherung der sicherheitskritischen Daten kommt bei Google Wallet daher ein Secure Element zur Anwendung. Dabei handelt es sich um ein Hardwaremodul, in dem Daten sicher abgelegt werden können. Der Zugriff auf dieses Modul und auf die darin gespeicherten Daten ist durch kryptographische Methoden abgesichert. Secure Elements können in Smartphones prinzipiell auf verschiedene Art und Weise realisiert werden. Denkbar sind etwa die Verwendung der SIM-Karte als Secure Element, die Erweiterung des Smartphones um eine spezielle Speicherkarte, die ein Secure Element enthält, oder auch die Verwendung eines Secure Elements, das fix in die Hardware des Smartphones integriert ist. Letzterer Ansatz wird von Google Wallet verfolgt. Ein Zugriff auf das Secure Element ist ausschließlich dem Betreiber der Backend-Systeme von Google Wallet im Zuge von Bezahlvorgängen über die NFC-Schnittstelle des Smartphones möglich. Der Zugriff muss darüber hinaus über eine spezielle Google Wallet Smartphone-App durch Eingabe einer geheimen PIN autorisiert werden. Dieser Umstand stellt zugleich auch den aus sicherheitstechnischer Sicht größten Unterschied zwischen Google Wallet und üblichen PayPass -fähigen Kreditkarten dar. Bankverbindung: BAWAG P.S.K. Konto Nr , BLZ 14000

2 Im Rahmen dieser Studie wird die Architektur und Funktionalität des mobilen Bezahlsystems Google Wallet näher analysiert. Dazu werden zunächst die zugrundeliegenden Technologien Near Field Communication (NFC) und Secure Elements allgemein beschrieben, sowie deren Integration in Smartphone-Architekturen diskutiert. Nach einer allgemeinen Beschreibung der Funktionalität von Google Wallet wird auch die Sicherheit dieser Lösung und die Tauglichkeit der eingesetzten Sicherheitsmechanismen analysiert. Hier zeigt sich, dass Google Wallet durchaus Vorteile gegenüber üblichen PayPass -basierten Zahlungsvorgängen hat, einige Implementierungsdetails jedoch mitunter die Sicherheit von Google Wallet speziell auf gerooteten Smartphones zu gefährden bedrohen. Update: Am 1. August 2012 gab Robin Dua, Head of Product Management, Google Wallet, in einem Blog [13] bekannt, dass Google Wallet ab sofort seine Strategie zur Speicherung von Kreditkartendaten ändert. Wurden diese bisher im Secure Element des Mobiletelefons sicher hinterlegt, verfolgt Google Wallet nun den Ansatz, diese Daten auf zentralen Google-Servern zu speichern. Laut offiziellen Angaben wird jedoch weiterhin eine eindeutige ID sicher auf dem Mobiltelefon hinterlegt, die für die Abwicklung von Bezahlvorgängen benötigt wird. Google verspricht sich von diesem geänderten Ansatz laut eigenen Angaben einen schnelleren Integrationsprozess für neue Karten durch Banken. Durch diesen Strategiewechsel sind einige der Konzepte, die in dieser Studie erläutert und diskutiert werden, für Google Wallet wohl nur mehr bedingt zutreffend. Genauere Details zur aktuellen Implementierung von Google Wallet sind jedoch zum aktuellen Zeitpunkt noch nicht bekannt. Allgemeine in dieser Studie angestellte Überlegungen zur NFC-Technologie und zur Verwendung von Secure Elements in Mobiltelefonen behalten jedoch natürlich weiterhin ihre Gültigkeit Studie_Google_Wallet.docx Seite: 2 von 27

3 Inhaltsverzeichnis 1. Einleitung 4 2. Technische Grundlagen Near Field Communication (NFC) Secure Elements 8 3. NFC und Secure Elements in Smartphones Allgemeine Architektur Implementierungsvarianten für Secure Elements Betriebsarten des Secure Elements Schnittstellen und Protokolle Secure Element Management Google Wallet Prozessablauf Setup von Google Wallet Verwendung von Google Wallet Technische Hintergrundinformationen Sicherheitsanalysen Analyse lokal gespeicherter Daten Angriff auf die geheime PIN Angriff auf die Prepaid-Funktionalität Fazit Ausblick Referenzen Studie_Google_Wallet.docx Seite: 3 von 27

4 1. Einleitung Ich trage eine Geldbörse mit mir, mein Vater hatte eine, mein Großvater auch. In zwei Jahren wird die verschwunden sein. John Donahow Präsident und Vorstandsvorsitzender von ebay Inc. DLD Konferenz München, Dieses Statement des aktuellen Präsidenten und Vorstandsvorsitzenden des Unternehmens ebay Inc. 1 scheint auf den ersten Blick einigermaßen gewagt, spiegelt jedoch sehr gut die aktuelle Erwartungshaltung vieler Unternehmen bezüglich alternativer bargeldloser Bezahlformen wider. Derzeit ist es vor allem das Schlagwort Mobile Payment, das häufig im Zusammenhang mit zukünftigen Bezahlformen genannt wird. Generell versteht man unter dem Begriff Mobile Payment einen Zahlungsprozess über einen mobilen Kanal, der unmittelbar mit einem Kauf verknüpft ist. Die Initiierung, Bestätigung, Autorisierung und Durchführung der finanziellen Transaktion beruht auf mobilen elektronischen Kommunikationstechnologien [1]. Neben dieser allgemeinen Definition werden in [1] zudem verschiedene Möglichkeiten der Kategorisierung unterschiedlicher Mobile Payment-Verfahren definiert. Demnach unterscheidet man im Rahmen von Mobile Payments allgemein zwischen Proximity Payments und Remote Payments. Unter Proximity Payments versteht man Zahlungen, die über ein Mobiltelefon initiiert werden und bei denen sich beide involvierten Parteien am selben Ort befinden und direkt miteinander über kontaktlose Übertragungstechnologien kommunizieren. Der Begriff Remote Payments umfasst hingegen Zahlungen, die über ein Mobiltelefon initiiert werden, bei denen die Transaktion jedoch über Telekommunikationsnetzwerke und somit unabhängig von der aktuellen Lokation des Zahlers durchgeführt werden kann. Alternativ dazu können bestehende Mobile Payment-Lösungen auch bezüglich des Kommunikationsmediums, über das der Bezahlvorgang initiiert wird, kategorisiert werden. Dabei können folgende Kategorien unterschieden werden. Zahlungen, die über NFC-Geräte initiiert werden Zahlungen, die über Applikationen auf mobilen Endgeräten initiiert werden Zahlungen, die durch den Scan eines Bildes (i.d.r. QR-Code) initiiert werden Zahlungen, die über SMS Nachrichten initiiert werden Zahlungen, die über einen Telefonanruf initiiert werden Schließlich können Mobile Payment-Methoden auch noch entsprechend dem Zeitpunkt, an dem für die gekaufte Ware oder die gekaufte Leistung bezahlt wird, unterschieden werden. Die sich aus dieser Unterscheidung ergebenden Kategorien werden hauptsächlich durch das Pre-paid Modell und das Post-paid Modell repräsentiert. Generelles Ziel aller Mobile Payment-Lösungen ist die einfachere und effizientere Abwicklung von Bezahlvorgängen, um einerseits die Benutzerzufriedenheit zu erhöhen und andererseits Kosten zu sparen. In den letzten Jahren fanden einige technologische Neuentwicklungen den Weg auf den Massenmarkt, welche die Implementierung einfacher und sicherer Mobile Payment-Lösungen ermöglichen. Smartphones stellen in diesem Zusammenhang eine der relevantesten Entwicklungen dar. Aktuelle Smartphones bieten Benutzerinnen und Benutzern neben den von Mobiltelefonen früherer Generationen bekannten Funktionen wie Telefonie und SMS eine Reihe weiterer Möglichkeiten. Durch ihre meist umfangreiche Ausstattung (z.b. GPS-Empfänger, Kompass, diverse Sensoren, etc.) und ihr breites Spektrum an verfügbaren Kommunikationsschnittstellen (GSM, UMTS, HSDPA, WLAN, NFC, Bluetooth, etc.) ermöglichen Smartphones die Entwicklung und den Betrieb vielfältiger Anwendungen. Als großer Vorteil erwies sich in diesem Zusammenhang auch die von Smartphones unterstützte flexible Softwareverwaltung. So können Smartphones durch die Installation zusätzlicher Softwaremodule Studie_Google_Wallet.docx Seite: 4 von 27

5 (Apps) sehr einfach erweitert und flexibel auf die persönlichen Bedürfnisse einzelner Benutzerinnen und Benutzer angepasst werden. Die technischen Möglichkeiten und die anhaltende Popularität von Smartphones prädestinieren diese Geräte für eine Verwendung im Rahmen von Mobile Payment-Lösungen. Dieses Potential wurde auch vom Unternehmen Google Inc. 2 erkannt, das seit einigen Monaten seinen mobilen Bezahldienst Google Wallet 3 in den USA anbietet. Langfristiges Ziel von Google Wallet ist es, Geldbörsen in Zukunft unnötig zu machen und die Abwicklung von Zahlvorgängen über Smartphones zu ermöglichen. Google Wallet basiert auf Near Field Communication (NFC). Diese Technologie ist seit kurzem auch in einigen Smartphones verfügbar und ermöglicht einen unkomplizierten kontaktlosen Datenaustausch zwischen verschiedenen NFC-fähigen Geräten. Damit ist diese Technologie für die Implementierung effizienter mobiler Zahlungsmethoden bestens geeignet. Die Popularität von Smartphones und die Fülle an mitunter auch sicherheitskritischen Applikationen, die für diese Geräte mittlerweile verfügbar sind, weckt naturgemäß auch das Interesse jener, die diese Systeme kompromittieren und für eigene Zwecke missbrauchen wollen. Die Gewährleistung der Sicherheit smartphonebasierter Mobile Payment-Lösungen ist daher von zentraler Bedeutung. Dies wurde auch von Google erkannt und im Mobile Payment-Verfahren Google Wallet entsprechend berücksichtigt. Die Sicherheit von Google Wallet beruht auf der Verwendung von Secure Elements. Ein Secure Element ist ein vertrauenswürdiges und sicheres Modul, das sicherheitskritische Daten speichern und verschiedene Operationen sicher durchführen kann. Smartphones bieten verschiedene Möglichkeiten um Secure Elements zu integrieren. So repräsentiert beispielsweise auch die SIM-Karte, die typischerweise in jedem Smartphone, das den GSM-Standard unterstützt, vorhanden ist, ein Secure Element. Darüber hinaus können weitere Secure Elements fix in ein Smartphone integriert sein, oder über vorhandene Schnittstellen (z.b. microsd-slot) eines Smartphones nachgerüstet werden. Für die Implementierung sicherheitskritischer Anwendungen auf Smartphones sind Secure Elements von zentraler Bedeutung. Mobile Payment-Lösungen sind dabei nur eines von vielen möglichen Anwendungsszenarien. Denkbar wäre beispielsweise auch der Einsatz von Secure Elements auf Smartphones zur mobilen Erstellung elektronischer Signaturen oder die sichere Speicherung privater oder sicherheitskritischer Daten. Eine Integration von Secure Elements in mobile Anwendungen setzt ein grundlegendes Verständnis der zugrundeliegenden Technologien voraus. Diese Studie beleuchtet technische Grundlagen und Möglichkeiten der Integration von Secure Elements in smartphonebasierte Lösungen. Da im Zusammenhang mit Secure Elements häufig auch NFC zum Einsatz kommt, wird auch diese Technologie im Rahmen dieser Studie näher vorgestellt. Die praktische Verwendung der diskutierten Technologien wird schließlich anhand der Mobile Payment-Lösung Google Wallet gezeigt. Dazu wird die prinzipielle Architektur von Google Wallet beschrieben, verfügbare technische Hintergrundinformationen aufbereitet und Sicherheitsaspekte dieser Lösung diskutiert. 2. Technische Grundlagen Google Wallet ist derzeit eine der vielversprechendsten Mobile Payment-Lösungen. In diesem Abschnitt werden die grundlegenden Technologien, denen sich Google Wallet bedient, um sichere Zahlungen zu gewährleisten, und die unter Umständen auch für andere sicherheitskritische Anwendungen interessant und hilfreich sein können, näher erläutert. Im Speziellen wird auf die beiden Technologien Near Field Communication (NFC) und Secure Elements eingegangen. Eine ausführliche Beschreibung der in diesem Abschnitt beschriebenen Technologien sowie weiterführende Informationen können einschlägiger Literatur (z.b. [2]) entnommen werden Studie_Google_Wallet.docx Seite: 5 von 27

6 2.1. Near Field Communication (NFC) Die NFC-Technologie wurde von den beiden Unternehmen NXP Semiconductors 4 und Sony 5 entwickelt und ist seit dem Jahr 2002 verfügbar. NFC ist eine Weiterentwicklung der RFID- Technologie, deren Entwicklung ebenfalls von den beiden oben genannten Unternehmen maßgeblich vorangetrieben wurde. Die Abkürzung RFID steht für Radio Frequency Identification und bezeichnet ein Verfahren zur kontaktlosen Übermittlung einfacher Daten. Ein RFID-System besteht in der Regel aus einem passiven Transponder oder RFID-Tag, in dem Daten gespeichert sind, und einem aktiven Lesegerät, über das diese Daten ausgelesen werden können. Die Datenkommunikation findet dabei in der Regel über ein vom Lesegerät erzeugtes magnetisches Wechselfeld oder durch hochfrequente Radiowellen statt. RFID-Tags verfügen über keine eigene Energieversorgung, sondern werden indirekt vom Lesegerät über dessen erzeugtes Feld versorgt. Dadurch können RFID-Tags sehr klein und billig produziert werden und stellen somit beispielsweise eine mögliche Alternative zu Barcodes dar. Abbildung 1 zeigt ein typische RFID-Tag, das beispielsweise anstelle eines Barcodes als Mittel zur Identifikation eines Produkts verwendet werden kann. Abbildung 1. Einen Großteil der Fläche eines RFID-Tags nimmt in der Regel dessen Antenne ein. [Graphik: Weit verbreitet sind aktuell die beiden proprietären RFID-Standards MIFARE (ISO/IEC 14443A 6 ) von NXP Semiconductors und FeliCa (Felicity Card) von Sony. NFC entstand aus einer Zusammenführung dieser beiden Standards und ermöglicht Übertragungsgeschwindigkeiten von bis zu 424 kbit/s. Die Reichweite der Kommunikation wurde bewusst gering gehalten und liegt bei maximal 10 cm. NFC erweitert die Möglichkeiten vorhandener RFID-Standards, ist zu jenen, die im Frequenzbereich von 13,56 MHz arbeiten, jedoch kompatibel. Die beiden relevantesten Standards, die Schnittstellen und Protokolle der NFC-Technologie spezifizieren, sind NFCIP-1 (spezifiziert in ECMA bzw. ISO/IEC ) und NFCIP-2 (spezifiziert in ECMA bzw. ISO/IEC ). Der wohl relevanteste Unterschied zwischen RFID und NFC ist die Aufhebung der strikten Rollenverteilung innerhalb eines RFID-Systems. Klassische RFID-Systeme bestehen immer aus einem aktiven Lesegerät und einem oder mehreren Transpondern. Die Transponder oder Tags sind dabei sehr minimalistisch ausgeführt und meist nur in der Lage, einfache Daten zur Verfügung zu stellen. Sämtliche Logik ist auf Seiten des Lesegeräts implementiert. Dieses ist auch für die Bereitstellung des Feldes verantwortlich, das einerseits zur Datenkommunikation verwendet wird, und über das andererseits der passive Transponder mit Energie versorgt wird. NFC ist in dieser Hinsicht flexibler und verzichtet auf eine derart strikte Trennung der Rollen. NFC- Geräte können sowohl aktiver als auch passiver Part der Kommunikation sein. Daraus ergeben sich insgesamt drei verschiedene Modi, in denen NFC-Systeme betrieben werden können Studie_Google_Wallet.docx Seite: 6 von 27

7 Peer-to-Peer-Modus: Dieser Modus erlaubt den bidirektionalen Datenaustausch zwischen zwei NFC-Geräten. Beispielsweise können zwei NFC-fähige Smartphones diesen Modus nutzen, um Daten (z.b. elektronische Visitenkarten) untereinander auszutauschen. Im Peer-to-Peer-Modus selbst können wiederum zwei verschiedene Kommunikationsmodi verwendet werden. Im passiven Kommunikationsmodus stellt der Initiator der Kommunikation das Trägersignal für die gesamte Kommunikation zur Verfügung. Zur Modulierung von Daten verwendet der Initiator Amplitudenmodulation (ASK). Die Antworten werden vom zweiten Kommunikationspartner über das Lastmodulationsverfahren übertragen. Da im passiven Kommunikationsmodus das Trägersignal für die gesamte Dauer der Kommunikation vom Initiator zur Verfügung gestellt wird, ist dieser Modus für den zweiten Kommunikationsteilnehmer sehr energiesparend. Im aktiven Kommunikationsmodus erzeugen hingegen beide Kommunikationsteilnehmer ihr eigenes Trägersignal. Beide Parteien verwenden Amplitudenmodulation zur Übertragung von Daten über das von ihnen generierte Feld. In diesem Modus ist der Energieverbrauch gerecht auf beide Kommunikationspartner aufgeteilt. In beiden Kommunikationsmodi sind sowohl der Verbindungsaufbau als auch der Datenaustausch detailliert durch die zugrundeliegenden Standards und verschiedene eigens entwickelte Protokolle festgelegt, deren ausführliche Behandlung jedoch den Rahmen dieser Studie sprengen würde. Der interessierte Leser sei an dieser Stelle an weiterführende Literatur (z.b. [2]) bzw. an die jeweiligen Spezifikationen verwiesen. Reader/Writer-Modus: Im Reader/Writer-Modus verhält sich ein NFC-Gerät wie ein RFID- Lesegerät. Dadurch ist das NFC-Gerät in der Lage, mit passiven RFID-Tags zu kommunizieren. Dieser Modus kommt beispielsweise bei der Verwendung von Smartpostern zum Einsatz. Diese enthalten ein passives RFID-Tag, das über NFC-fähige Smartphones ausgelesen werden kann. Die an das Smartphone übertragenen Daten können auf diesem entsprechend angezeigt werden oder aber Aktionen direkt am Smartphone auslösen. Beispielsweise könnte über das Auslesen des Smartposters direkt eine bestimmte URL im Browser des Smartphones geöffnet werden. Card-Emulation-Modus: Im Card-Emulation-Modus verhält sich ein NFC-Gerät wie eine kontaktlose Smartcard. In diesem Modus kann das NFC-Gerät mit standardkonformen RFID-Lesegeräten kommunizieren. Der Funktionsumfang der emulierten Smartcard wird grundsätzlich durch den NFC-Chipsatz determiniert und kann ein breites Spektrum abdecken. Die Smartcard kann neben der Software des NFC-Geräts auch von einem vorhandenen Secure Element emuliert werden. Dieses ist mit dem NFC-Baustein des Geräts verbunden und übernimmt die Durchführung sicherheitskritischer Operationen. Im Gegensatz zum Peer-to-Peer-Modus wird die Kommunikation im Card-Emulation-Modus ausschließlich vom NFC-Chipsatz gesteuert und läuft somit unabhängig von der übrigen Hard- und Software des NFC-Geräts. Dadurch kann der Card-Emulation-Modus auch bei ausgeschaltetem NFC-Gerät betrieben werden. Wird der NFC-Chipsatz außerdem über das vom Initiator bereitgestellte Feld versorgt, kann der Card-Emulation-Modus auch ohne eigene Energieversorgung betrieben werden. Dies ist vor allem ein für Smartphones interessantes Szenario. Bedeutet es doch, dass das NFC-Modul eines Smartphones unter Umständen auch noch bei leerem Akku des Smartphones weiter funktionstüchtig bleibt. Da NFC wie auch RFID auf einer kontaktlosen Datenübertragung basiert, ergeben sich mehrere Angriffsvektoren, die die Sicherheit NFC basierter Systeme unter Umständen kompromittieren können. Vor allem bei der Implementierung sicherheitskritischer Lösungen müssen diese Gefahren berücksichtigt werden. Allgemein können für NFC folgende Gefahrenpotentiale identifiziert werden. Abhören der drahtlosen Kommunikation und Verwendung der erhaltenen Daten im Rahmen einer Replay-Attacke. Man-in-the-Middle-Attacken, in denen sich ein Angreifer zwischen die beiden Kommunikationspartner platziert. Ersetzen des Kommunikationspartners durch Austausch desselbigen oder durch schnelleres Beantworten von Befehlen Studie_Google_Wallet.docx Seite: 7 von 27

8 Störung und Beeinflussung der Datenkommunikation. Einige dieser Angriffsszenarien können durch den Einsatz kryptographischer Verfahren verhindert oder zumindest erheblich erschwert werden. Zur Absicherung des Peer-to-Peer-Modus wurde die Normenreihe NFC-SEC 11 entwickelt. NFC-SEC definiert zwei grundlegende Dienste. Der Shared Secret Service unterstützt den Austausch eines gemeinsamen Schlüssels, der in weiterer Folge von Anwendungen zur Verschlüsselung von Daten verwendet werden kann. Der Secure Channel Service ermöglicht hingegen den Aufbau eines sicheren Kanals zwischen den beiden Kommunikationsteilnehmern und somit einen verschlüsselten und authentisierten Datenaustausch Secure Elements Secure Elements spielen in vielen sicherheitskritischen Anwendungen eine zentrale Rollen. Die Idee, sicherheitsrelevante Funktionen in eine logischen oder physikalischen Einheit zusammenzufassen, ist nicht neu. Dies wurde etwa als Trusted Computing Base in den 1980er Jahren populär, später wurden unter dem Begriff Trusted Computing und Trusted Platform Module (meist am PC) verbaute Harware-Elemente verstanden. Auch im täglichen Leben kommen weitere Secure Elements häufig zur Anwendung. Beispielsweise repräsentieren Chipkarten ein Secure Element, das zum Beispiel die sichere Authentifizierung an Bankautomaten (Geldausgabegeräte, etc.) ermöglicht. Der Zugriff auf das Secure Element bzw. auf die darin sicher gespeicherten Daten ist dabei in der Regel über eine PIN geschützt. Secure Elements spielen auch in NFC-basierten Anwendungen oft eine wichtige Rolle. Hier ermöglichen sie die sichere Speicherung von Daten und die sichere Durchführung von Operationen im Rahmen des Card-Emulation-Modus. Auch das Mobile Payment-Verfahren Google Wallet, das im Rahmen dieser Studie noch näher vorgestellt wird, verwendet ein Secure Element zur sicheren Speicherung benutzerbezogener Daten. Secure Elements spielen vor allem auf Smartphones eine wichtige Rolle. Während Smartphones Benutzerinnen und Benutzern eine Vielzahl an Funktionen bieten, sehen diese Geräte oft keinen geschützten Datenbereich vor, der gegen Angriffe und unerlaubten Zugriff speziell geschützt wäre. Secure Elements schaffen hier Abhilfe, indem sie folgende Funktionalität zur Verfügung stellen. Sicherer Speicher für sicherheitskritische Daten Kryptographische Operationen Sichere Umgebung zur Ausführung von Programmcode Durch diese Eigenschaften sind Secure Elements beispielsweise in der Lage, als sichere Signaturerstellungseinheit gemäß EU Signaturrichtlinie [6] zu fungieren. Private Signaturschlüssel können im Secure Element sicher gespeichert werden. Da das Secure Element in der Lage ist, kryptographische Operationen durchzuführen, können elektronische Signaturen direkt im Secure Element berechnet werden, ohne dass der private Signaturschlüssel die geschützte Umgebung im Zuge des Signaturerstellungsprozesses verlassen muss. Durch die o.g. Eigenschaften bieten Secure Elements eine solide Grundlage für die Implementierung sicherheitskritischer Anwendungen auf Smartphones. Vor allem im Zusammenhang mit der NFC-Technologie ergeben sich durch die Einbeziehung von Secure Elements zahlreiche Möglichkeiten, das potentiell unsichere mobile Gerät auch für sicherheitskritische Operationen nutzen zu können. Obwohl Secure Elements durchaus Ähnlichkeiten zu Smartcards aufweisen, gibt es doch vor allem in Hinblick auf den typischen Lebenszyklus entscheidende Unterschiede. Chipkarten sind in dieser Hinsicht relativ einfach gestaltet: Alle Applikationen werden bereits vor Ausgabe der Karte im Rahmen eines speziellen Personalisierungsschritts installiert und konfiguriert (allenfalls sind wie bei Java Card nachladbare Anwendungen möglich). Im Gegensatz dazu weisen Secure Elements einen deutlich komplexeren Lebenszyklus auf, was jedoch auch zu deren Flexibilität beiträgt Studie_Google_Wallet.docx Seite: 8 von 27

9 Generell kann der Lebenszyklus eines im Rahmen einer mobilen NFC-Anwendung eingesetzten Secure Elements in die folgenden vier Abschnitte unterteilt werden. Initialisierung: Im Zuge der Initialisierung legt der Herausgeber des Secure Elements (Platform Provider) grundlegende Parameter des Secure Elements fest und gibt dieses an den Anwender aus. Optional kann in diesem Schritt auch ein Verwalter für das Secure Element festgelegt werden (Platform Manager). Dieser kann im Zuge der Initialisierung bereits Applikationen am Secure Element installieren. Aktivierung: Wurde während der Initialisierung noch kein Platform Manager festgelegt, wird dies im Rahmen der Aktivierung nachgeholt. Die Aktivierung findet grundsätzlich während der ersten Verwendung des Secure Elements statt. In dieser Phase wird das Secure Element für eine Verwendung im jeweiligen mobilen Gerät freigegeben. Verwaltungsphase: Die Verwaltungsphase umfasst jene Zeitspanne, in der das Secure Element einsatzbereit ist und von Dienstanbietern zur Absicherung ihrer Dienste verwendet werden kann. Dienstanbieter können dazu beim Platform Manager Bereiche des Secure Elements anfordern. Diese Bereiche (Security Domains) werden vom Platform Manager dynamisch vergeben und können in weiterer Folge durch Dienstanbieter verwendet werden. Jeder Dienstanbieter hat dabei ausschließlich auf die ihm zugewiesene Security Domain Zugriff. Die Verwaltung des Secure Elements erfolgt über ein Over-the-Air (OTA) Interface und kann somit jederzeit unabhängig vom Standort des mobilen Geräts durchgeführt werden. Deaktivierung: Die Deaktivierung kann vom Platform Manager durchgeführt werden und beendet die Verwaltungsphase. Nach einer Deaktivierung ist das Secure Element nicht mehr einsatzbereit. Für eine neuerliche Verwendung muss das Secure Element erneut aktiviert werden. Ein entscheidender Vorteil von Secure Elements ist die Tatsache, dass die Funktionalität des Secure Elements im Zuge der Verwaltungsphase dynamisch geändert werden kann. Dienstanbieter haben die Möglichkeit, in der ihnen zugewiesenen Security Domain beliebige Anwendungen sogenannte Applets zu installieren. Mit diesen kann dann über die vorhandenen Interfaces des Secure Elements (z.b. auf APDU-Ebene, d.h. den unmittelbaren Kartenprotokollen) kommuniziert werden. Die installierten Anwendungen können die Eigenschaften des Secure Elements (sichere Datenspeicherung, sichere Ausführung von kryptographischen Operationen, etc.) nutzen, um ein entsprechendes Niveau an Sicherheit zu gewährleisten. 3. NFC und Secure Elements in Smartphones Google Wallet verwendet zur Implementierung einer sicheren Mobile Payment-Lösung sowohl die NFC-Technologie als auch Secure Elements. Beide Technologien kommen dabei direkt am Smartphone der Benutzerin bzw. des Benutzers zur Anwendung. Die typische Integration dieser Technologien in aktuelle Smartphone-Architekturen wird im Folgenden näher beschrieben. Detaillierte weiterführende Informationen zu diesem Thema finden sich unter anderem in [2] Allgemeine Architektur Die von einem NFC-System auf einem Smartphone implementierte Funktionalität ist in der Regel auf vier Hauptkomponenten aufgeteilt. Abbildung 2 zeigt die involvierten Komponenten und deren Beziehungen zueinander. Der Host/Basisband-Controller fungiert als zentrale Komponente des Smartphones und umfasst alle Module, die zur Ausführung des Mobiltelefonbetriebssystems nötig sind. Dazu gehören unter anderem Kommunikationsschnittstellen (GSM, UMTS, Bluetooth, etc.), Peripheriegeräte, oder auch die Benutzerschnittstelle (Display, Tastatur, etc.). Am Host-Controller laufen alle nicht oder wenig sicherheitskritischen Anwendungen. So wird am Host-Controller beispielsweise auch der NFC-Protokollstack ausgeführt. Man spricht im Zusammenhang mit dem Host/Basisband- Controller auch von einem Application Execution Environment (AEE). Für die Durchführung sicherheitskritischer Operationen wird hingegen das Secure Element herangezogen. Aufgrund Studie_Google_Wallet.docx Seite: 9 von 27

10 dessen geschützter Umgebung spricht man beim Secure Element von einem Trusted Execution Environment (TEE). Zentrales Element des NFC-Systems ist der NFC-Controller. Der NFC-Controller stellt die Verbindung zwischen den Komponenten des Smartphones und der analogen NFC-Schnittstelle dar. Dementsprechend verfügt der NFC-Controller über ein analoges Front-End zur Ansteuerung der Antenne, als auch über eine digitale Schnittstelle, über die der NFC-Controller mit anderen Komponenten des Smartphones kommuniziert. Der NFC-Controller arbeitet daher unter anderem als Modulator und Demodulator (Modem), um Daten über die Antenne zu senden bzw. um Daten von der Antenne entsprechend zu empfangen. Host/Basisband Controller NFC Controller Secure Element Antenne Abbildung 2. NFC-Systeme in Smartphones bestehen in der Regel aus vier Hauptkomponenten. [Graphik adaptiert von [2]] Der NFC-Controller unterstützt in der Regel alle vom NFC-Standard definierten Kommunikationsmodi (Peer-to-Peer-Modus, Reader/Writer-Modus, Card-Emulation-Modus). Je nach Implementierung kann der NFC-Controller darüber hinaus noch weitere RFID-Standards unterstützen. In der Regel wird der NFC-Controller so wie auch alle anderen Komponenten des Smartphones vom Akkumulator des mobilen Geräts mit Energie versorgt. Im Card-Emulation-Modus von NFC kann es jedoch notwendig sein, dass die NFC-Funktionalität des Smartphones auch bei leerem Akku weiterhin zur Verfügung steht. Beispielsweise ist es wünschenswert, dass im Secure Element gespeicherte Tickets auch bei leerem Smartphone-Akku weiterhin zu Verfügung stehen und bei Bedarf ausgelesen werden können. Moderne NFC-Controller sind daher in der Lage, die für einen minimalen Betrieb nötige Energie auch aus dem NFC-Feld zu beziehen. Grundlegende Funktionen wie das Auslesen von im Secure Element gespeicherten Informationen sind damit auch bei entleertem Smartphone-Akku weiterhin möglich. Der NFC-Controller kann an den Host-Controller und damit an andere Komponenten des Smartphones über verschiedene Schnittstellen angebunden sein. Häufig kommen dazu SPI (Serial Peripheral Interface Bus), I²C (Inter-Integrated Circuit Bus), UART (Universal Asynchronous Receiver/Transmitter), oder auch USB (Universal Serial Bus) zum Einsatz. Der NFC-Controller kann optional auch mit einem oder mehreren Secure Elements verbunden sein. Die Kommunikation mit den Secure Elements erfolgt dabei zumeist über SWP (Single Wire Protocol) oder das NFC Wired Interface (NFC-WI). Aus Sicht des NFC-Controllers verhalten sich die Secure Elements dabei wie Smartcards Implementierungsvarianten für Secure Elements Zur Bereitstellung der von Secure Elements geforderten Funktionalität sind prinzipiell verschiedene Implementierungen denkbar. Unter Berücksichtigung der auf Smartphones gegebenen Studie_Google_Wallet.docx Seite: 10 von 27

11 Möglichkeiten reduziert sich jedoch der Kreis möglicher Realisierungsvarianten. Trotzdem sind auch auf Smartphones verschiedene Umsetzungen möglich. Alle derzeit verfügbaren Varianten sind in Abbildung 3 ersichtlich und können prinzipiell in die Kategorien Software, Integrierte Hardware und Austauschbare Hardware unterteilt werden. Softwarebasierte Lösungen sind hier nur der Vollständigkeit halber erwähnt. Klarerweise kann die Funktionalität eines Secure Elements auch in Software implementiert und emuliert werden. Für derartige Lösungen ergeben sich jedoch keinerlei Sicherheiten gegen unerlaubten Zugriff und Manipulation. Diese können nur von hardwarebasierten Implementierungen garantiert werden. Secure Element Integrierte Hardware Software Austauschbare Hardware Basisband- Controller Dedizierter SE-Chip UICC SMC Dedizierter SE-Chip Abbildung 3. Implementierungsvarianten für Secure Elements auf Smartphones. [Graphik adaptiert von [2]] Bei hardwarebasierten Lösungen unterscheidet man allgemein zwischen Modulen, die integraler Bestandteil des Smartphones sind und mit diesem eine untrennbare Einheit bilden, und Modulen, die über vorhandene Schnittstellen des Smartphones mit diesem verbunden werden können. Bei integrierten Lösungen kann das Secure Element Teil des Basisband-Controllers sein. Alternativ kann das Secure Element auch als eigener Chip ausgeführt, jedoch fix mit dem Smartphone verbunden sein. Aktuelle Lösungen folgen zumeist letzterem Ansatz. Der Nachteil einer integrierten Lösung liegt in der Bindung des Secure Elements und er darin gespeicherten Daten an ein spezielles Smartphone. Muss das Smartphone getauscht werden, so kann das Secure Element nicht einfach auf das neue Gerät übertragen werden. Dieses Problem kann mit austauschbarer Hardware umgangen werden. Ist das Secure Element als austauschbares Hardware-Modul implementiert, ergeben sich wiederum verschiedene Umsetzungsmöglichkeiten. Auch hier kann das Secure Element als dedizierter Chip realisiert werden. Für diesen wäre jedoch ein separater Slot oder eine ähnliche adäquate Schnittstelle am Smartphone nötig. Da der Platz auf Smartphones generell limitiert ist, wird diese Variante von Herstellern kaum präferiert. Eine weitere Möglichkeit der Realisierung eines Secure Elements ergibt sich durch die in jedem GSM-fähigen Mobiltelefon vorhandene SIM-Karte. Der Begriff SIM- Karte beschreibt eigentlich die UICC (Universal Integrated Circuit Card). Die UICC repräsentiert eine sichere Plattform, in der neben der wohlbekannten SIM-Applikation zur Authentifizierung der Teilnehmerin bzw. des Teilnehmers am Mobilfunknetz auch noch weitere Anwendungen sicher ausgeführt werden können. Die UICC erfüllt damit alle Anforderungen eines Secure Elements. Da die UICC jedoch in der Regel an einen bestimmten Mobilfunkbetreiber gebunden ist, ergeben sich bei einem Wechsel des Mobilfunkbetreibers ähnliche Probleme wie beim Wechsel eines Smartphones mit fest integriertem Secure Element. Die aus Benutzersicht wohl komfortabelste Lösung scheint daher die Verwendung einer sogenannten Secure Memory Card (SMC) zu sein. Dabei handelt es sich um Speicherkarten (z.b. im micro-sd-format), die zusätzlich mit einem Secure Element ausgestattet sind. Diese Karten können über vorhandene Schnittstellen (z.b. micro-sd-slot) mit dem Smartphone verbunden und in Folge vom Smartphone aus angesprochen werden. Bei einem Wechsel des Mobiltelefons oder des Mobilfunkbetreibers kann die Karte mit dem Secure Element einfach auf das neue Gerät Studie_Google_Wallet.docx Seite: 11 von 27

12 übertragen werden. Abbildung 4 zeigt ein derartiges Secure Element von Giesecke & Devrient 12, das in eine micro-sd-karte integriert ist. Abbildung 4. Manche Speicherkarten enthalten ein integriertes Secure Element, das für die Durchführung sicherheitskritischer Operationen verwendet werden kann. [Graphik: Betriebsarten des Secure Elements Unabhängig von der Realisierung des Secure Elements kann dieses auf unterschiedliche Art und Weise eingesetzt werden. Abbildung 5 zeigt die möglichen Betriebsarten und die involvierten Komponenten. Im externen Modus kommuniziert das Secure Element mit einem externen Lesegerät. Das Secure Element emuliert dabei eine kontaktlose Smartcard. Der NFC-Controller, über den die gesamte Kommunikation läuft, fungiert hier lediglich als Vermittler. Der NFC- Controller kommuniziert mit dem externen Lesegerät über die Antenne und das NFC-Feld. Das Secure Element ist an den NFC-Controller in der Regel über SWP oder NFC-WI angebunden. Smartphone Host/Basisband Controller Interner Modus NFC Controller Secure Element Externes Lesegerät Externer Modus Abbildung 5. Betriebsarten des Secure Elements. [Graphik adaptiert von [2]] Alternativ kann das Secure Element auch im internen Modus betrieben werden. Auch in diesem Modus emuliert das Secure Element eine kontaktlose Chipkarte, die jedoch nun vom Host/Basisband-Controller angesprochen wird. Dieser fungiert in diesem Fall als Lesegerät. Sämtliche Kommunikation wird auch in diesem Betriebsmodus über den NFC-Controller geleitet. Eine Ausnahme bilden hier nur Secure Elements, die über eine UICC implementiert sind. Diese Studie_Google_Wallet.docx Seite: 12 von 27

13 verfügt neben der Anbindung über den NFC-Controller auch über eine direkte Verbindung zum Host/Basisband Controller. Eine UICC verfügt im Allgemeinen über mehrere Schnittstellen. Zum einen kann die UICC über eine ISO/IEC 7816 kompatible Schnittstelle angesprochen werden. Diese wird unter anderem für die SIM-Applikation benötigt. Aktuelle UICC verfügen darüber hinaus auch bereits über eine USB- Anbindung. Eine Secure Element UICC ist schließlich auch noch über das Single Wire Protocol (SWP) mit dem NFC-Controller des Smartphones verbunden. Dadurch kann die UICC auch noch im Card-Emulation-Modus betrieben werden, wenn das restliche Smartphone bereits nicht mehr vom Akku versorgt werden kann. Somit können vom Secure Element der UICC auch im ausgeschalteten Zustand des Smartphones Daten über die NFC-Schnittstelle vom Secure Element der UICC gelesen werden Schnittstellen und Protokolle Die Kommunikation zwischen den einzelnen involvierten internen Komponenten beruht auf diversen spezifizierten Schnittstellen und Protokollen. Abbildung 6 zeigt relevante Protokolle, die bei NFC-basierten Lösungen intern zur Anwendung kommen. NFC Controller NFC-WI SWP HCI HCI Proprietäres Protokoll Secure Element HCI Host/Basisband Controller Abbildung 6. Schnittstellen und Protokolle. [Graphik adaptiert von [2]] Kurz erwähnt wurden bereits das NFC Wired Interface (NFC WI) Protokoll, sowie das Single Wire Protocol (SWP). Sowohl NFC-WI als auch SWP spezifizieren die Schnittstelle zwischen dem NFC- Controller und einem Secure Element. NFC WI ist in ECMA und ISO/IEC spezifiziert und beruht auf einer digitalen 2-Draht-Schnittstelle. Allgemein wurde das NFC WI Protokoll für die Kommunikation zwischen einem NFC-Front-End und einem NFC-Transceiver entwickelt. In dem in Abbildung 6 skizzierten Fall übernimmt das Secure Element die Rolle des NFC-Transceivers, während der NFC-Controller als Front-End fungiert. NFC WI unterstützt drei verschiedene Übertragungsraten. Je nach Datenrate kommen zur Kodierung der zu übertragenden Daten unterschiedliche Methoden zur Anwendung (Tabelle 1). Tabelle 1. Verwendete Kodierungsverfahren zur Datenübertragung bei NFC WI. Datenrate Transceiver Front-End Front-End Tranceiver 106 kbit/s Manchester-Kodierung und anschließende logische ODER- Verknüpfung mit 848 khz Takt 212 kbit/s Manchester-Kodierung Miller-Kodierung und anschließende logische UND-Verknüpfung mit 13,56 MHz Takt Machester-Kodierung und anschließende XOR-Verknüpfung mit 13,56 MHz Takt (PSK-Modulation des Taktsignals) Studie_Google_Wallet.docx Seite: 13 von 27

14 424 kbit/s Manchester-Kodierung Machester-Kodierung und anschließende XOR-Verknüpfung mit 13,56 MHz Takt (PSK-Modulation des Taktsignals) Neben dem NFC WI Protokoll, kommt auch das Single Wire Protocol (SWP) bei der Kommunikation zwischen NFC-Controller und Secure Element zum Einsatz. Eine Alternative zum NFC WI wurde nötig, nachdem auch UICC als Secure Elements eingeführt wurden. Grund dafür ist die durch den zugrundeliegenden Standard (ISO/IEC ) vorgegebene maximale Anzahl von acht Kontakten, über die eine UICC verfügen kann (siehe Abbildung 7). Fünf dieser acht Kontakte sind mit der Spannungsversorgung VCC und GND, sowie den Signalen CLK, I/O und RST bereits vergeben. Weitere zwei Kontakte sind bei UICCs für eine USB-Schnittstelle vorgesehen. Mit dem einen verbleibenden Kontakt kann das NFC WI Protokoll nicht mehr umgesetzt werden, da dieses auf zwei getrennten Leitungen beruht. Aus diesem Grund wurde als Alternative das Single Wire Protocol (SWP) entwickelt und in ETSI TS spezifiziert. Die einzige verbleibende Leitung kann im Full-Duplex-Modus verwendet werden, indem das Signal von der UICC (Secure Element) zum NFC-Controller als Stromsignal, und das Signal vom NFC- Controller zur UICC als Spannungssignal interpretiert wird. Abbildung 7. Typisches Layout der Kontakte einer UICC. [Graphik: Basierend auf diesen (und potentiell anderen proprietären) Protokollen kommt für die Kommunikation zwischen NFC-Controller und Secure Element häufig auch das HCI (Host Controller Interface) Protokoll zum Einsatz. Dabei handelt es sich um ein High-Level-Protokoll, das hauptsächlich für die Kommunikation zwischen UICC und NFC-Controller gedacht, aber grundsätzlich nicht auf diese beiden Komponenten beschränkt ist. Beim HCI-Protokoll repräsentiert der NFC-Controller die zentrale Komponente. Da dieser physikalische Verbindungen zu allen anderen involvierten Komponenten und Modulen (UICC, Secure Elements, Basisband-Controller) hält, ist er für das Routing von Datenpakten zwischen den anderen Komponenten, die unter Umständen über keine direkte physikalische Verbindung verfügen, zuständig. Das HCI-Protokoll unterstützt die Definition mehrerer logischer Endpunkte (Gates). Verbindungen zwischen zwei Gates (Pipes) dienen dem Datenaustausch zwischen beliebigen Komponenten. Damit erlaubt das HCI-Protokoll eine Kommunikation zwischen Komponenten, die über keine direkte physikalische Verbindung verfügen. Die zu transferierenden Daten werden für die beiden Kommunikationsteilnehmer transparent über den NFC-Controller als zentrale Instanz geleitet. Das HCI-Protokoll ist prinzipiell flexibel einsetzbar. Beispielsweise verwendet der NFC-Controller PN544 der Firma NXP Semiconductors das HCI sowohl für die Kommunikation mit der UICC als auch für die Kommunikation mit dem Basisband-Controller. HCI wurde ursprünglich für die Kommunikation zwischen UICC und NFC-Controller entwickelt und optimiert. Dadurch ist dieses Protokoll zwar grundsätzlich auch für die Kommunikation zwischen NFC-Controller und Basisband- Controller geeignet, zeigt jedoch durchaus noch Verbesserungspotential. Bestehende Mängel sollen in Zukunft durch den Einsatz des NFC Controller Interface (NCI) Protokolls, das in Hinblick auf eine Optimierung der Kommunikation zwischen Basisband-Controller und NFC-Controller entwickelt wurde, behoben werden Studie_Google_Wallet.docx Seite: 14 von 27

15 3.5. Secure Element Management Im Rahmen von NFC-basierten Anwendungen auf Smartphones spielen Secure Elements für die Gewährleistung der Sicherheit eine entscheidende Rolle. Aus diesem Grund kommt auch der Verwaltung der Secure Elements auf mobilen Geräten eine entscheidende Bedeutung zu. Unter Verwaltung versteht man dabei im Allgemeinen die Installation, Personalisierung und Löschung von Daten und Anwendungen am Secure Element. Wie bereits weiter oben ausgeführt, können Secure Elements auf Smartphones und anderen mobilen Geräten auf unterschiedliche Art und Weise implementiert werden. Unabhängig von der jeweiligen Implementierung ist der innere Aufbau von Secure Elements stets ähnlich und folgt prinzipiell den GlobalPlatform-Spezifikationen [3]. Auch die Verwendung und das Management von Secure Elements im Rahmen von NFC-Anwendungen wurde von der GlobalPlatform-Organisation bereits behandelt [4]. Im Rahmen der GlobalPlatform-Spezifikationen wird dabei zumeist von der Verwendung einer UICC als Secure Element ausgegangen. Die definierten Konzepte sind jedoch auch auf andere Secure Element-Realisierungen anwendbar. Die zentrale dabei zur Anwendung kommende Technologie ist das Over-the-Air (OTA) Management. Dabei werden Anwendungen über einen zentralen Server über die GSM oder UMTS Schnittstelle des mobilen Geräts direkt am Secure Element (oder auch direkt im NFC-Gerät) verwaltet. Die Kommunikation erfolgt dabei über den Host-/Basisband-Controller des Mobiltelefons. Bei NFC-basierten Systemen übernimmt ein Trusted Service Manager (TSM) die Rolle der zentralen Server-Komponente und ist damit für die Verwaltung der einzelnen Applikationen (Applets) am Secure Element verantwortlich. Die GlobalPlatform-Spezifikationen definieren die Rolle eine Trusted Service Managers, um die Verwaltung von Anwendungen auf Secure Elements zu vereinheitlichen und damit zu vereinfachen. Verschiedene Diensteanbieter können eine einheitliche Instanz zur Verwaltung von Anwendungen beauftragen bzw. verwenden. Gleichzeitig bietet der TSM für Mobilfunkbetreiber eine einheitliche Schnittstelle zu verschiedenen Dienstanbietern. Abbildung 8 illustriert die Verwendung des Trusted Service Managers. Ohne diesen müsste jeder Dienstanbieter zu jedem Mobilfunkbetreiber über eine eigene Anbindung verfügen, was mit steigender Anzahl von Dienstanbietern und Mobilfunkbetreibern, sowie einer wachsenden Verbreitung der Dienste rasch zu einer schwer beherrschbaren Komplexität führen würde. Dienstanbieter A Dienstanbieter B Dienstanbieter C Dienstanbieter D Trusted Service Manager Mobilfunkbetreiber A Mobilfunkbetreiber B Mobilfunkbetreiber C Abbildung 8. Verwendung des Trusted Service Managers (TSM) [Graphik adaptiert von [2]] Durch die Verwendung des Trusted Service Managers wird die Verwaltung von Secure Elements für Dienstanbieter entscheidend vereinfacht. Die zwischen Dienstanbietern und Mobilfunkbetreibern ausgetauschten Nachrichten beruhen auf der GlobalPlatform Messaging Specification [5]. Im Rahmen der Verwaltung von Secure Elements bzw. der auf den Secure Elements installierten Anwendungen über die OTA-Schnittstelle unterscheidet die GlobalPlatform-Spezifikation zwischen den folgenden drei Modi. Alle Varianten und mögliche Untervarianten sind im GlobalPlatform White Paper zu Secure Element Management [4] ausführlich erklärt. Simple Mode: Die Verwaltung des Secure Elements (Initialisierung, Personalisierung, Verwaltung und Löschung von Anwendungen) wird ausschließlich vom Mobilfunkbetreiber Studie_Google_Wallet.docx Seite: 15 von 27

16 durchgeführt und vom Trusted Service Manager lediglich überwacht. Die gesamte Verwaltung findet über die OTA-Plattform des Mobilfunkbetreibers statt. Delegated Mode: In diesem Modus ist die Verwaltung des Secure Elements an einen Trusted Service Manager delegiert. Allerdings muss für jede Operation explizit die Zustimmung des Mobilfunkbetreibers eingeholt werden. Im Delegated Mode kann der Trusted Service Manager eine eigene OTA-Plattform verwenden. Authorized Mode: Die Verwaltung ist vollständig an den Trusted Service Manager ausgelagert. Zu diesem Zweck verfügt dieser auf dem Secure Element über einen eigenen geschützten Bereich. Auch in diesem Modus kann der Trusted Service Manager eine eigene OTA-Plattform verwenden. Die drei genannten Varianten unterscheiden sich hauptsächlich in der für die Durchführung des Managements verantwortlichen Rolle. Dadurch ergeben sich unterschiedliche Geschäftsfälle, die je nach Anwendungsszenario verschiedene Vor- und Nachteile bieten können. Alle Varianten ermöglichen jedoch aus technischer Sicht eine sichere Verwaltung von Secure Elements. 4. Google Wallet Google Wallet wurde im Mai 2011 von Google vorgestellt. Die grundsätzliche Idee von Google Wallet ist es, bargeldlose Bezahlvorgänge zu vereinfachen. Dazu verfolgt Google Wallet den Ansatz, die Geldbörse (Wallet) und speziell die darin enthaltenen Karten zu virtualisieren. Dazu werden von Google Wallet derzeit zwei unterschiedliche Lösungen angeboten. Einerseits bietet Google Wallet die Möglichkeit, das eigene Android-Smartphone als virtuelle Geldbörse zu verwenden um dieses anstelle von Kreditkarten beispielsweise bei Ladeneinkäufen zu verwenden. Andererseits bietet Google Wallet auch einen Cloud 17 -basierten Dienst, der die Bezahlung von Online-Einkäufen vereinfachen soll. Der Fokus dieser Studie liegt auf der smartphonebasierten Lösung, deren Architektur und Sicherheit im Folgenden ausführlicher diskutiert werden soll. Um einen einfachen Bezahlvorgang über Smartphones zu ermöglichen, bedient sich Google Wallet der in Abschnitt 2.1 diskutierten NFC-Technologie, die auf ausgewählten Android- Smartphones bereits verfügbar ist. Zur Gewährleistung der Sicherheit des implementierten Prozesses sieht das Konzept von Google Wallet außerdem die Verwendung von Secure Elements vor. Google Wallet basiert damit im Prinzip auf jenen Konzepten, die in Abschnitt 3 dieser Studie näher vorgestellt wurden. Tatsächlich ist die Verwendung der NFC bzw. RFID-Technologie für die Durchführung bargeldloser Zahlungen kein neuer Ansatz. Vor allem in den USA sind derartige Verfahren bereits etabliert. Als Beispiel kann hier der von MasterCard 18 angebotene Dienst PayPass 19 genannt werden. MasterCard PayPass erlaubt Kundinnen und Kunden die bargeldlose Bezahlung mit speziellen RFID-fähigen Karten. MasterCard PayPass -Karten enthalten also ein RFID-Tag, über das die Karte eindeutig identifiziert werden kann. Eine Bezahlung kann durchgeführt werden, indem diese Karten an speziellen Terminals mit integriertem RFID-Lesegerät vorbeigezogen werden. Auf diese Weise können Beträge bis zu einem gewissen Limit (i.d.r. 25 US$) ohne vorherige Authentifizierung der Benutzerin oder des Benutzers rasch und unkompliziert bezahlt werden. Google Wallet kann als Weiterentwicklung oder Ergänzung dieses Verfahrens betrachtet werden, das statt einer RFID-fähigen Karte ein NFC-fähiges Smartphone verwendet. Weitere Unterschiede zu etablierten RFID-basierten Bezahlmethoden werden in dieser Studie noch näher herausgearbeitet. Nach dessen Vorstellung im Mai 2011 wurde Google Wallet für einige Monate im Rahmen einer Pilotierungsphase in den US-amerikanischen Städten New York und San Francisco getestet. Nach dieser Testphase wurde Google Wallet schließlich im September 2011 in allen US-amerikanischen 17 Als Cloud Computing wird allgemein der Ansatz bezeichnet, spezielle Ressourcen und Dienste nachfrageorientiert über eine zentrale IT-Infrastruktur anzubieten und bedarfsmäßig abzurechnen Studie_Google_Wallet.docx Seite: 16 von 27

17 Bundestaaten gestartet. Neben Google waren vor allem Citigroup Inc. 20 als kreditkartenausgebendes Bankinstitut, MasterCard International Inc. 21 als Kreditkartenherausgeber, der Mobilfunkbetreiber Sprint 22 und die First Data Corporation 23 als Betreiber der Backend-Systeme in Entwicklung und Betrieb von Google Wallet maßgeblich involviert. Da Google Wallet vorerst ausschließlich auf dem Android-Smartphone Nexus S 4G verwendet werden kann, können vorerst nur Sprint-Kunden, die über ein derartiges Smartphone verfügen, Google Wallet verwenden. Diese müssen außerdem entweder über eine von Citi herausgegebene MasterCard Kreditkarte verfügen, oder aber eine Google Prepaid-Karte verwenden. Andere Kreditkarten werden derzeit noch nicht unterstützt. Google bemüht sich jedoch laut eigenen Angaben, hier bald eine breitere Unterstützung anbieten zu können. In diesem Abschnitt soll Google Wallet näher vorgestellt und verschiedene Aspekte dieser Mobile Payment-Lösung diskutiert werden. Dazu wird Google Wallet in den folgenden Unterabschnitten zunächst aus Sicht von Benutzerinnen und Benutzern vorgestellt, gesammelte technische Hintergrundinformationen entsprechend aufbereitet und die Sicherheit dieser Lösung analysiert Prozessablauf Aus Sicht von Benutzerinnen und Benutzern gliedert sich die Verwendung von Google Wallet in zwei Abschnitte. Der erste Schritt Setup muss dabei nur einmal ausgeführt werden. Der folgende Schritt Verwendung kann nach dem erfolgreichen Setup hingegen beliebig oft wiederholt werden. Beide Schritte werden im Folgenden näher beschrieben Setup von Google Wallet Bevor Google Wallet verwendet werden kann, muss die Applikation am Smartphone der Benutzerin bzw. des Benutzers installiert und eingerichtet werden. Dazu müssen folgende Schritte durchgeführt werden. Die Verwendung von Google Wallet setzt die Installation der Google Wallet Android App voraus. Anders als die meisten anderen Android-Apps ist Google Wallet nicht im Android Market (Google Play) 24 verfügbar. Kundinnen und Kunden des US-amerikanischen Mobilfunkbetreibers Sprint erhalten die App automatisch über ein OTA-Update auf ihr Smartphone. Alternativ kann die App auch über ein manuell angestoßenes System-Update auf dem Mobiltelefon installiert werden. Zu beachten ist, dass die Google Wallet App nur auf kompatiblen Smartphones installiert werden kann. Derzeit werden nur die Modelle Nexus S und Galaxy Nexus unterstützt. Nach Erhalt und Installation der App muss diese initialisiert werden. Im Rahmen der Initialisierung müssen Benutzerinnen und Benutzer den Geschäftsbedingungen (Service Agreement) zustimmen und einen Google-Account auswählen, mit dem in weiterer Folge die Zahlungsinformationen verknüpft werden sollen. Dabei kann ein bestehender und dem Smartphone bereits zugeordneter Account verwendet, oder ein neuer Account hinzugefügt werden. In einem letzten Schritt muss schließlich noch eine geheime PIN für die App festgelegt werden. Zu einfache PIN-Varianten (ausschließlich gleiche Ziffern, aufeinanderfolgende Ziffern) werden von der App nicht akzeptiert Verwendung von Google Wallet Nachdem die Google Wallet App am Smartphone erfolgreich initialisiert wurde, kann diese verwendet werden. Die App erlaubt einerseits die Verwaltung verschiedener virtueller Karten und andererseits die Durchführung von Bezahlvorgängen mit diesen Karten. Diese beiden Anwendungsszenarien werden im Folgenden näher beschrieben Studie_Google_Wallet.docx Seite: 17 von 27

18 Verwaltung virtueller Karten Google Wallet unterstützt eine Vielzahl an verschiedenen Karten. Zur Bezahlung von Gütern oder Diensten können Kreditkarten (aktuell PayPass-konforme MasterCard Kreditkarten der Citibank), sowie Google Prepaid-Karten verwendet werden. Daneben unterstützt Google Wallet auch noch diverse Geschenk- und Kundenkarten ausgewählter Händler. Auf die einzelnen Kartenkategorien kann über ein Menü zugegriffen werden (Abbildung 9). Neue Karten können über die Kartenübersicht, die durch Berühren des Payment cards-icons aufgerufen werden kann, hinzugefügt werden. Dieser Vorgang benötigt einen Internetzugang. Um eine virtuelle Kreditkarte zu Google Wallet hinzuzufügen, müssen die Kartendaten der entsprechenden Kreditkarte eingegeben werden. Unter anderem sind die Kreditkartennummer, der CVC-Code der Karte, das Ablaufdatum, der Name der Kartenbesitzerin oder des Kartenbesitzers, der Zip-Code und das Geburtsjahr erforderlich. Zusätzlich muss für jede virtuelle Karte ein Nick- Name definiert werden, unter dem die Karte in der Google Wallet App dann aufscheint. Abbildung 9. Google Wallet unterstützt neben Kreditkarten auch noch Geschenk- und Kundenkarten. Über ein Menü kann auf die verschiedenen Kartenkategorien zugegriffen werden. [Graphik: Studie_Google_Wallet.docx Seite: 18 von 27

19 Abbildung 10. In der Kartenübersicht der Google Wallet App sind alle virtuellen Karten gelistet. Durch Berühren des Kartensymbols können weitere Details zur jeweiligen Karte angezeigt werden. [Graphik: Nach Eingabe der Kreditkartendetails werden diese online beim Kreditkartenunternehmen verifiziert. Nach erfolgter Verifikation steht der Benutzerin bzw. dem Benutzer ein 100$ Limit zur Verfügung, im Rahmen dessen die Karte bereits für Bezahlvorgänge eingesetzt werden kann. Um das volle Limit der Karte auszuschöpfen, muss die Karte nach erfolgter Verifikation aktiviert werden. Benutzerinnen und Benutzer werden nach dem Hinzufügen neuer virtueller Karten automatisch zum Aktivierungs-Interface der App weitergeleitet. Alternativ kann dieses Interface auch durch Berühren des Buttons Enter activiation code, der sich in der Kartenübersicht unter nichtaktivierten Karten befindet, erreicht werden. Zur Aktivierung von virtuellen Karten muss ein gültiger Aktivierungscode eingegeben werden. Dieser wird entweder per , SMS, über einen Anruf, oder auch auf dem Postweg zugestellt. Es werden dabei jene Kontaktdaten verwendet, die der verwendeten physikalischen Kreditkarte zugeordnet sind. Im Rahmen der Aktivierung kann die aktivierte Karte auch als Default-Karte festgelegt werden. In diesem Fall wird diese Karte standardmäßig für alle Bezahlvorgänge verwendet. Neben der Citi MasterCard Kreditkarte unterstützt Google Wallet bislang auch noch Google Prepaid-Karten für Bezahlvorgänge. Die Google Prepaid-Karte ist nach Installation und Setup der Google Wallet App bereits der Kartenübersicht hinzugefügt. Durch Berühren des Kartensymbols, das diese virtuelle Karte repräsentiert, kann die Google Prepaid-Karte aktiviert werden. Nach erfolgter Aktivierung der Aktivierungsprozess kann bis zu fünf Minuten dauern ist die Karte einsatzbereit und bereits mit einem zeitlich begrenztem Guthaben von 10$ aufgeladen. Nach Auswahl der Google Prepaid-Karte in der Kartenübersicht der Google Wallet App kann durch Berühren des Add funds Buttons weiteres Guthaben auf die Karte geladen werden. Zum aktuellen Zeitpunkt kann neues Guthaben ausschließlich über eine Kreditkarte hinzugefügt werden. Während die Verwendung virtueller Kreditkarten auf Citi MasterCard Karten beschränkt ist, können zum Aufladen der Google Prepaid-Karte auch andere Kreditkarten verwendet werden. Um neues Guthaben auf die Prepaid-Karte zu laden, müssen zunächst die Details der Kreditkarte, mit der das Guthaben bezahlt werden soll, bekanntgegeben werden. Nach Bekanntgabe der Karteninformationen kann der gewünscht Betrag gewählt werden. Dieser muss zumindest 20$ betragen. Wurden alle Angaben von der Benutzerin bzw. vom Benutzer bestätigt, wird der gewählte Betrag in der Regel innerhalb einer Minute auf die Prepaid-Karte gebucht. Der aktuell verfügbare Betrag ist jederzeit unterhalb des Kartensymbols der Google Prepaid-Karte in der Kartenübersicht der App ersichtlich. Nach Auswahl einer virtuellen Karte in der Kartenübersicht der Google Wallet App kann diese Karte auch gelöscht werden. Zum Entfernen einer Karte kann der Eintrag Delete card des Kartenmenüs verwendet werden. Durchführung von Bezahlvorgängen Wurde die Google Wallet App erfolgreich installiert und konfiguriert, gestaltet sich die Durchführung von Bezahlvorgängen aus Sicht der Benutzerin bzw. des Benutzers relativ unkompliziert. Prinzipiell sind Bezahlvorgänge an allen Terminals möglich, die mit dem MasterCard PayPass Logo (Abbildung 11) versehen sind. Google Wallet kann also prinzipiell als Implementierung einer MasterCard PayPass Kreditkarte gesehen werden. Abbildung 11. Bezahlvorgänge mit Google Wallet sind an allen Terminals mit diesem Logo möglich Studie_Google_Wallet.docx Seite: 19 von 27

20 Zum Start des Bezahlvorgangs muss das Smartphone eingeschalten und dessen Bildschirm aktiviert sein (Abbildung 12). Dies ist notwendig, da nur bei aktiviertem Bildschirm auch der NFC- Transceiver des Smartphones, der für die Durchführung des Bezahlvorgangs benötigt wird, aktiv ist. Für die Durchführung des Bezahlvorgangs muss die Google Wallet App gestartet werden. Dies kann durch Auswahl des entsprechenden Symbols im App-Menü des Smartphones bewerkstelligt werden. Alternativ wird die Google Wallet App auch automatisch gestartet, sobald das Smartphone an das PayPass -Terminal gehalten wird (Abbildung 13). Das Smartphone sollte dabei 2,5 bis 5,0 Zentimeter vom Terminal entfernt sein. Abbildung 12. Zum Start des Bezahlvorgangs muss zunächst der Bildschirm des Smartphones aktiviert werden. [Graphik: Google] Abbildung 13. Das Smartphone muss zur Durchführung des Bezahlvorgangs an das MasterCard PayPass -Terminal gehalten werden. [Graphik: Google] Nach dem Start der Google Wallet App wird die Benutzerin bzw. der Benutzer zur Eingabe der geheimen PIN aufgefordert. Ja nach konfigurierter Gültigkeitsdauer muss die PIN bei folgenden Bezahlvorgängen nicht mehr eingegeben werden (Abbildung 14). Um Missbrauch zu verhindern, empfiehlt sich die Wahl eines möglichst kurzen Gültigkeitsbereichs, sodass die PIN bei jedem Bezahlvorgang erneut eingegeben werden muss. Standardmäßig ist hier ein Wert von fünf Minuten eingestellt. Abbildung 14. Unmittelbar nach Start der Google Wallet App ist die Eingabe der geheimen PIN erforderlich. [Graphik: Google] Studie_Google_Wallet.docx Seite: 20 von 27