1 Einleitung

Einkäufe mit dem Handy zu bezahlen klingt zunächst einmal at-traktiv: Viele tragen das Smartphone ohnehin ständig bei sich, ein Verlust wird sofort bemerkt und mit Hilfe von GSM-Verbin-dung und Display lassen sich neue Anwendungen zur Kunden-bindung umsetzen, die mit herkömmlichen Kreditkarten nicht möglich waren. Tatsächlich existiert die Idee, Plastikkreditkar-ten durch Smartphones zu ersetzen bereits, seit 1997. Doch erst mit zunehmender NFC-Unterstützung in aktuellen Smartphone-Modellen und Bezahlterminals sind die Weichen für Mobile Pay-ment gestellt. Mittlerweile unterstützt mit Ausnahme von Apples iPhone jedes High-End-Smartphone NFC und es existieren Spe-zifikationen für das kontaktlose Bezahlen nach dem EMV-Stan-dard1, die bereits von vielen Bezahlterminals unterstützt werden. Erste Pilotanwendungen in verschiedenen europäischen Ländern versprechen Erfolge.

Doch wie sicher ist das Bezahlen per Funk eigentlich? Müs-sen Benutzer in Zukunft fürchten, qua Berührung bestohlen zu werden?

2 Near Field Communication

Um diese Fragen zu beantworten, lohnt sich zunächst ein Blick auf die eigentliche Übertragungstechnik, die für die Verbindung zwi-

1 https://www.emvco.com/

schen dem Smartphone und dem Bezahlterminal eingesetzt wird. Near Field Communication (NFC) ist eine Variante der RFID-Sys-teme, die sich jedoch in einem wesentlichen Punkt von anderen Protokollen dieser Familie unterscheidet. RFID umfasst sämtli-che Technologien zur Übertragung von Daten auf kurzen Distan-zen, wobei sich die Technologien über das gesamte Spektrum er-strecken – von robusten Niedrigfrequenzsystemen über Hochfre-quenzsysteme für SkiPässe und berührungslose Bezahlkarten, bis hin zu ultrahochfrequenten Systemen mit relativ hoher Reichwei-te, wie sie etwa für Fahrzeugschlüssel eingesetzt werden.

NFC ist lediglich ein Ausschnitt dieser RFID-Systeme und be-wegt sich mit 13.56 MHz im hochfrequenten Bereich. Im Gegen-satz zu den meisten Systemen, wie auch dem nach wie vor weit verbreiteten MIFARE-System, zeichnet sich NFC jedoch durch die besondere Eigenschaft aus, dass es sowohl aktiv, als auch pas-siv betrieben werden kann. Während MIFARE oder die in Asi-en weit verbreiteten FeliCa-Karten stets mit passiven Karten ar-beiten, die Spannung induktiv aus einem durch den Kartenle-ser aufgebauten Feld beziehen, unterstützt NFC mehrere Modi:

Im Reader/Writer-Modus (PCD) verhält sich ein NFC-Gerät wie ein Lesegerät für kontaktlose Smartcards und könnte somit z.B. als Bezahlterminal arbeiten.

Im Card Emulation Modus (PICC) verhält sich das NFC-Ge-rät wie eine Smartcard. Es ist also passiv und muss durch ein Lesegerät angesprochen werden. Da das Gerät in diesem Modus Spannung per Induktion aus dem Feld des Lesegerätes beziehen kann, kann der Card Emulation Modus auch mit leerer Smart-phone-Batterie genutzt werden, wenn die Batterie eines Smart-phones, was natürlich gerade im Zusammenhang mit Bezahl- oder Schließssystemen interessant ist.

Im Peer-to-Peer-Modus schließlich kommunizieren zwei akti-ve NFC-Geräte miteinander, wobei das Feld für die Datenüber-tragung jeweils wechselnd von beiden Geräten zur Verfügung ge-stellt wird.

Durch die verschiedenen Betriebsmodi ergeben sich unter-schiedliche Konstellationen für mobile Bezahlanwendungen. So kann das Smartphone sowohl als Bezahlterminal arbeiten, als auch als kontaktlose Kreditkarte. Über den Peer-to-Peer-Modus

Dr. Julian Schütte

ist Co-Leiter des Bereichs Sichere Dienste und Anwendungen des Fraunhofer AISEC und dort u.a. verantwortlich für die Sicherheitsanalyse mobiler Anwendungen.

E-Mail: julian.schuette@aisec.fraunhofer.de

Julian Schütte

NFC? Aber sicher.

Wie sicher ist das kontaktlose Bezahlen?

Mit Ausnahme von Apples iPhone zählt NFC mittlerweile zur Grundausstattung jedes High-End-Smartphone und neue Anwendungen wie Mobile Payment halten derzeit Einzug. Doch das so praktische Bezahlen mit dem Smartphone hat auch Tücken. NFC bietet keinerlei Sicherheitsmechanismen und Apps sind leicht anzugreifen. Schon zeichnet sich eine ganze Reihe neuer Angriffsszenarien ab. Verschiedene Sicherheitsmechanismen können Abhilfe schaffen, doch ihr Einsatz hat sowohl technische, als auch organisatorische Hürden.

20 DuD • Datenschutz und Datensicherheit 1 | 2014

SCHWERPUNKT

wäre es darüber hinaus möglich, Zahlungen direkt von Benutzer zu Benutzer vorzunehmen.

Doch von diesen vielfältigen Einsatzmöglichkeiten ist Mobi-le Payment noch weit entfernt. Dabei stellt die Sicherheit dieser Anwendungen derzeit einer der größten Herausforderungen dar.

Die Übertragung erfolgt stets unverschlüsselt und NFC selbst bietet keinerlei Mechanismen zur Geheimhaltung der gesendeten Daten. Selbst Verfahren zur Reduktion von Interferenzen wie das Frequency Hopping von Bluetooth, die das Abhören zwar nicht unmöglich, aber zumindest aufwändiger machen, sind in NFC nicht vorgesehen, da die Sendereichweite nur wenige Zentimeter beträgt und Interferenzen mit anderen Sendern daher kein Pro-blem darstellen.

Ein adäquates Sicherheitsfeature ist die kurze Distanz jedoch nicht, wie bereits in der Vergangenheit gezeigt wurde [1]. Zum ei-nen lässt sie sich mit wenig Aufwand auf mehrere Meter auswei-ten, zum anderen existieren Angriffe, bei denen Kommunikation zunächst durch einen Rogue-Reader an das eigentliche Lesegerät weitergeleitet wird. Damit wird auch der Schutz gegen Man-in-the-Middle-Angriffe ausgehebelt, der NFC an sich aufgrund der kurzen Reichweite innewohnen sollte.

Um das Auslesen und Wiedereinspielen der Kommunikation zu verhindern, verlegen sich NFC-basierte Anwendungen daher auf kryptographische Protokolle, die oberhalb von NFC aufset-zen. Letztlich basiert die Sicherheit von NFC-Anwendungen al-so weniger auf den NFC-Standards selbst, sondern auf geeigne-ten Systemarchitekturen und Protokollen, die auf Anwendungs-ebene realisiert werden müssen.

Anhand von mobilen Bezahlsystemen lässt sich gut veran-schaulichen, dass es hierbei keinen Königsweg gibt, sondern dass durchaus ganz unterschiedliche Lösungen zum Einsatz kommen können. Es wird aber auch offenbar, dass der Einsatz von NFC in sicherheitsrelevanten Anwendungen alles andere als trivial ist. Zumal es nicht nur technische Herausforderungen zu meistern gilt. Das Mobile Bezahlen eröffnet neue Märkte und die damit einhergehenden Interessenlagen von Smartphone-Herstellern, Netzwerkbetreibern, Payment-Anbietern und weiteren Playern müssen in Einklang gebracht werden.

3 Mobile Payment

Auch wenn es im Umfeld von Mobile Payment ganz unter-schiedliche Einsatzszenarien gibt, bezeichnet der Begriff in der Regel das kontaktlose Bezahlen mit dem Smartphone an einem Point-of-Sale (POS) Terminal. Dabei kommt der weit verbreite-te EMV-Standard in der kontaktlos-Variante zum Einsatz. War bis vor kurzem das kontaktlose Bezahlen noch eine Nischentech-nologie, nimmt seine Verbreitung derzeit rasch zu. Alleine VISA strebt für Deutschland eine Verbreitung von 2 Millionen kontakt-losen EMV-Karten bis Ende 2013 an und annährend 200.000 Ter-minals sind bereits für diese Technologie vorbereitet.

3.1 Online- vs. Offline-Payment

Aus Sicherheitssicht ist vor allem die Unterscheidung in Online- und Offline-Payment wichtig. Bei ersterem steht das POS-Termi-nal z.B. über GSM in Verbindung mit einem Backend und lässt die Transaktion verifizieren. D.h., nicht nur die von der Kredit-karte erzeugte Signatur kann geprüft werden, auch zusätzliche

Plausibilitäts- und Bonitätsprüfungen können durch das Backend vorgenommen werden, so dass z.B. gesperrte Karten sofort er-kannt werden. Insofern ist Online-Payment zwar das sicherere Verfahren, allerdings ist es oft nicht anwendbar, da ein Großteil der Händler nicht über eine ständige Internetverbindung am Be-zahlterminal verfügt. Schon innerhalb von Gebäuden sind Mo-bilfunkverbindungen problematisch. Oft sind auch die Verzöge-rungen, die mit einem Online-Abgleich einhergehen nicht ak-zeptabel, wie zum Beispiel an Ticketautomaten. Als Alternative bietet EMV daher das Offline-Payment, bei dem die Verifikati-on der Transaktion direkt im Bezahlterminal erfolgt. Zwar kann so nicht die Bontiät geprüft werden, doch die Smartcard kann si-cherstellen, dass die PIN korrekt ist und dass bestimmte Limits nicht überschritten werden. Damit bleibt das Risiko für den Pay-ment-Anbieter zumindest begrenzt und kalkulierbar.

3.2 Bezahlen mit dem Smartphone

Der Vorteil des EMV-basierten Mobile Payment liegt darin, dass es mit diesen Bezahlverfahren und den aktuellen Terminals kom-patibel ist und daher bereits jetzt großflächig eingesetzt werden kann. Das Smartphone verhält sich dem Terminal gegenüber ähnlich einer kontaktlosen Kreditkarte – mit einigen kleinen, aber doch wichtigen Unterschieden:

Bei Mobile-Payment wird die PIN nicht in das Terminal einge-geben, sondern direkt in das Smartphone. Auch Informationen wie der Betrag oder der Name des Händlers werden im Display des Telefons angezeigt.

Weiter reicht es für EMV-kompatibles Bezahlen aus, wenn die NFC-Kommunikation zwischen Smartphone und POS-Termi-nal dem Standard entspricht. Wie die kritischen Daten seitens des Smartphones verarbeitet werden, kann hingegen von Anbieter zu Anbieter variieren. Gerade hier liegt die größte Schwachstelle von Mobile Payment und das Potential für umfangreiche Angriffe. Bieten Smartcard-basierte Kreditkarten durch speziell geschütz-te Hardware, ein überschaubares Betriebssystem, und dedizierte Payment-Anwendungen ein sehr hohes Maß an Softwaresicher-heit, so sieht die Lage bei Smartphones anders aus. Anstelle der sicheren Smartcard verwenden Benutzer nun ein System, das per se unsicher ist. Smartphone-Plattformen sind nicht speziell ge-schützt, die Bezahlanwendung ist nur eine neben vielen, poten-tiell auch bösartigen Apps und außer NFC stehen diverse wei-tere, potentiell angreifbare, Schnittstellen zur Außenwelt bereit.

3.3 Neubewertung der Sicherheit ist erforderlich

Dabei bestehen die Herausforderungen nicht nur darin, die An-wendungen auf dem Smartphone abzusichern. Auch verschiede-ne Annahmen, die für die als relativ sicher geltenden EMV-Pay-ment-Verfahren getroffen wurden, werden durch Mobile Payment in Frage gestellt und müssen komplett neu bewertet werden. An-dernfalls tut sich bei einer naiven Umsetzung eine ganze Reihe von neuen Angriffsvektoren auf:

3.3.1 Extrahieren von Geheimnissen aus der App

Die PIN und Signaturschlüssel auf dem mobilen Endgerät kön-nen ausgespäht werden.

Anders als eine Smartcard bietet eine App keinerlei Möglich-keit, Geheimnisse sicher zu verwahren. Der Einsatz von Signa-

DuD • Datenschutz und Datensicherheit 1 | 2014 21

SCHWERPUNKT

turschlüsseln, wie sie für EMV-Offline-Payment benötigt wer-den ist damit nicht ohne weiteres möglich. Auch die Keychain von iOS oder der Keystore von Android bieten hierfür kein ad-äquates Schutzniveau.

3.3.2 Manipulation der App

Payment-Apps können manipuliert werden, so dass sie Geheim-nisse preisgeben und Transaktionslimits nicht mehr prüfen. Ge-rade auf der Android-Plattform ist es sehr einfach, existierende Apps zu modifizieren. Dies wird dann zum Problem, wenn ein Payment-Verfahren auf Sicherheitsmechanismen innerhalb der App basiert. Diese können mit geringem Aufwand modizifiert oder entfernt werden.

3.3.3 Phishing-Apps

Über Phishing-Apps kann die PIN gestohlen und ungewollte Transaktionen veranlasst werden. Ebenso wie bei Online-Ban-king-Webseiten basiert die Sicherheits von Mobile Payment-An-wendungen oftmals auf der Authentizität der App. Für den Be-nutzer ist es jedoch alles andere als offensichtlich, ob er es gera-de mit der legitimen App seines Bezahldienstleisters, oder mit ei-ner gut gemachten Fälschung zu tun hat. Die Prüfungen der App Stores sind für eine Erkennung solcher Phishing-Apps nicht aus-gelegt. Apple wendet vor Freigabe einer App eine Mischung aus automatischer Analyse auf Schwachstellen, sowie einer manuel-len Inspektion der App an, wobei sich diese insbesondere auf die Inhalte der App konzentriert. Google hingegen setzt ausschließ-lich auf eine automatische Prüfung der Apps. Beide Verfahren sind nicht dazu geeignet, Phishing-Apps zu enttarnen, so dass auf beiden Plattformen als einzige Möglichkeit die Fernlöschung der schädlichen Apps verbleibt, nachdem sie entdeckt wurden.

3.3.4 Remote-Relay-Angriffe

Ein Relay-Angriff ermöglicht es einem Angreifer, aus der Ferne Nachrichten einzuschleusen, als würden sie über das NFC-Inter-face empfangen. Die Payment-App geht folglich davon aus, mit ei-nem in direkter Nähe befindlichen Bezahlterminal über NFC zu kommunizieren – tatsächlich kommuniziert sie jedoch über das Internet mit einem Rechner des Angreifers. Gelingt es nun noch, die PIN des Benutzers auszuspähen, kann der Angreifer beliebige Transaktionen im Namen des Benutzers veranlassen, ohne dass eine tatsächliche NFC-Verbindung vonnöten wäre. Dieser An-griff stellt eine der größten Bedrohungen dar, da er vom Backend des Payment-Anbieters kaum erkannt werden kann – schließlich werden gültige Transaktionen über ein legitimes Terminal durch-geführt. Darüber hinaus skaliert der Angriff, d.h. eine Vielzahl von Endgeräten kann infiziert und auf die gleiche Weise ange-griffen werden, was es unmöglich macht, ihn per Risikomanage-ment zu kontrollieren.

Um diese Angriffsszenarien in den Griff zu bekommen, existie-ren mehrere Maßnahmen, die jedoch sinnvoll miteinander kom-biniert werden müssen.

4 Sicherheit mit Hardware-Unterstützung

Eine naheliegende Möglichkeit ist es, auch im Mobiltelefon auf die Hardware-Sicherheit von “Secure Elements“ zurückzugreifen, um Geheimnisse zu speichern und Kommunikation über NFC zu schützen. Tatsächlich enthält jedes aktuelle Smartphone meist so-gar mehrere Chips, die als ein solcher Smartcard-Ersatz verwen-det werden können.

Bei aktuellen Android-Smartphones wird die NFC-Funktiona-lität durch ein Secure Element bereitgestellt, das mehrere Funk-tionen in sich vereint: Den NFC-Controller, eine Emulation des populären MIFARE-Speicherkartensystems, sowie einen Smart-card-Prozessor mit entsprechender Kryptographie-Unterstüt-zung. In der Regel ist diese JavaCard-kompatibel und könnte mit der gleichen Software bestückt werden, die auch in der herkömm-lichen Kreditkarte eingesetzt wird. Diese technisch an sich ele-gante Lösung wird jedoch von aktuellen Mobile Payment-An-wendungen nicht genutzt, da der Zugang zum Secure Element in der Regel nicht möglich ist. So versucht Google seine Bezahlan-wendung Google Wallet umzusetzen und ermöglicht es Drittan-bietern nicht, eigene Kreditkartenanwendungen auf das Secure Element aufzubringen. Als Alternative bleibt ab Android 4.4 nur der Host Card Emulation Mode (HCE), der es Android-Apps er-laubt, sich nach außen als Smartcard-Applet darzustellen – ohne die Hardware-Sicherheit eines Secure Elements.

Ein Alternative ist die Verwendung der SIM-Karte als uni-verseller Smartcard-Plattform – der sog. UICC. Hiermit lässt sich ebenfalls ein Schutzniveau erreichen, das einer Smartcard ebenbürtig wäre. Allerdings gelten hier die gleichen Schwierig-keiten: Die SIM-Karte ist Eigentum der Netzbetreiber und die-se sind ebenfalls daran interessiert, ihre eigenen Bezahlanwen-dungen umzusetzen, weshalb der Zugang zur UICC nicht allge-mein möglich ist.

Als Alternative verbleibt die Verwendung von Secure Elements in Form einer microSD-Karte, die der Benutzer in das Smart-phone einstecken muss. Entsprechende Produkte sind verfügbar und stellen die Funktionalität einer Smartcard, ggf. in Kombina-tion mit NFC Card Emulation zur Verfügung. Zwar bringt auch das eine Reihe Nachteile mit sich – z.B. verfügen nicht alle Smart-phones über einen microSD-Kartenslot, doch es ist derzeit die praktikabelste Möglichkeit, Hardware-Sicherheit in mobilen Be-zahlanwendungen zu verwenden und über NFC Card Emulation zu kommunizieren. Doch das Sicherheitsniveau dieser Variante ist nicht ganz so hoch wie das der zuvor genannten. Da der Zugriff auf das Secure Element nicht integraler Bestandteil der Plattform ist, sondern durch separate Treiber von Drittanbietern realisiert wird, verlässt man sich zum einen darauf, dass diese proprietären Treiber keine Fehler aufweisen. Zum anderen gibt es keinerlei Zu-griffskontrolle innerhalb der Smartphone-Plattform, so dass je-de App auf das Secure Element zugreifen und es entweder sper-ren, oder – unter Kenntnis der PIN – sogar Transaktionen auslö-sen könnte. Nichtsdestotrotz ist eine enge Integration von NFC-Controller und Secure Element äußerst sinnvoll, da Remote-Re-lay-Angriffe erschwert werden und sicherheitskritische Operatio-nen wie die Überprüfung der PIN oder die Verwaltung von Signa-turschlüsseln in der geschützten Umgebung des Secure Element realisiert werden können.

22 DuD • Datenschutz und Datensicherheit 1 | 2014

SCHWERPUNKT

5 Die Kreditkarte in der Cloud

Derzeit überwiegen die praktischen Probleme beim Einsatz von integrierten Secure Elements und UICCs. MicroSD-Karten mit Secure-Element-Funktion an Benutzer zu verteilen, ist für vie-le Anbieter ebenfalls wenig attraktiv. Eine alternative Architek-tur sieht daher vor, das Secure Element in das Internet auszula-gern und das Smartphone lediglich als Gateway zwischen dem Bezahlterminal und dem gehosteten Secure Element zu verwen-den. Diese Lösung ist für Anbieter von Bezahlanwendungen in-sofern interessant, als das sie sich nicht mit den Netzwerkbetrei-bern, Smartcard-Issuern oder sonstigen Eigentümern der siche-ren Hardware auseinandersetzen müssen und sie mit jedem NFC-fähigen Smartphone genutzt werden kann.

Allerdings ist auch diese Architektur nicht optimal: Zwar ist der Ansatz, sämtliche Geheimnisse außerhalb des unsicheren Smartphones zu speichern, durchaus sinnvoll. In der Praxis je-doch steht nicht immer eine Internetverbindung am Bezahlter-minal zur Verfügung. Daher müssen auch bei dieser Architektur wieder Geheimnisse in Form von vorberechneten Tokens auf dem Telefon gespeichert werden, mit denen eine begrenzte Anzahl an Transaktionen durchgeführt werden kann. Je nach Smartphone-Plattform und Konfiguration sind solche lokal gespeicherten To-kens relativ einfach auszulesen, so dass das Risiko durch eine Be-schränkung auf nur wenige vorberechnete Transaktionen limi-tiert werden sollte.

6 Einwegkreditkarten

Das Problem der mangelnden Plattformsicherheit und die He-rausforderungen in Bezug auf die Integration von Sicherheits-Hardware lässt sich auch auf eine recht elegante Art und Weise umgehen: Anstelle zu versuchen, einen geheimen Signaturschlüs-sel im Telefon zu schützen und Revokationsmechanismen für den Fall des Verlusts oder Diebstahls des Geräts zu implementieren, kann für jede einzelne Transaktion eine Einweg-Kreditkarte ge-neriert werden, die nur für eine einzige Verwendung gültig ist. Diese Architektur erfordert zwar eine Anpassung der Signatur-prüfung im Backend seitens des Anbieters, doch sie löst einige Si-cherheitsprobleme und macht das Bezahlverfahren unabhängig von der Smartphone-Hardware. Derzeit sind verschiedene Vari-anten dieses Ansatzes in der Entwicklung oder bereits in der Pi-lotphase. Das grundsätzliche Vorgehen ist ihnen stets gemein: Aus den Transaktionsdaten, der PIN des Benutzers, sowie einem Zeitstempel wird eine zufällige Kreditkartennummer inklusive Prüfsumme und Gültigkeitsdatum erzeugt. Die so erstellten Da-ten werden mit einem Einmal-Geheimnis unterschrieben und per NFC als normale EMV-Transaktion übertragen. Im Online-Be-zahlverfahren leitet das Terminal diese gültige EMV-Transakti-on zur Prüfung an das Backend weiter, das wiederum validiert, ob die Einweg-Kreditkarte durch einen legitimen Benutzer un-ter Verwendung der korrekten PIN erzeugt wurde. Diese Prüfung weicht natürlich von der herkömmlichen Signatur-basierten Vali-dierung ab, doch sie liegt im Einflussbereich des Anbieters der Be-zahlanwendung und kann daher entsprechend angepasst werden.

Während diese Architektur ein hohes Maß an Sicherheit bie-tet und auf Ebene der NFC-Kommunikation mit dem Kartenle-ser vollständig kompatibel mit den existierenden EMV-Standards ist, so funktioniert sie jedoch nur im Online-Payment-Verfahren.

Im Offline-Verfahren prüft das Bezahlterminal direkt, ob eine Transaktion mit einem gültigen Signaturzertifikat unterschrie-ben wurde – was offensichtlich nicht der Fall ist und zur Ableh-nung der Transaktion führen würde.

7 Sichere PIN-Eingabe

Alle bisher vorgestellten Varianten haben eines gemein: Der Be-nutzer muss seine geheime PIN in ein unsicheres Gerät eingeben – sein Smartphone. Damit unterscheidet sich das Mobile Pay-ment grundsätzlich von herkömmlichen Verfahren, bei denen das Geheimnis in ein gesichertes Lesegerät eingegeben wird, das ge-nau diesem einen Zweck dient und eine spezielle Sicherheitsklasse einhalten muss. Anders bei Mobile Payment: Hier wird die PIN-Eingabe am Telefon in der jeweiligen Payment-App vorgenom-men. Doch wie kann sich der Benutzer sicher sein, dass das gerade angezeigte PIN-Eingabefeld tatsächlich das der Payment-App ist und nicht etwa von einer Phishing-App erzeugt wurde? Und wie wird sichergestellt, dass die eingegebene PIN nicht durch Schad-software im Hintergrund aufgezeichnet wird? Belege, dass dies funktioniert gibt es genug. So reicht die Palette der Angriffe von relativ simplen Methoden, wie dem registrieren eines bösartigen Custom-On-Screen-Keyboards bis hin zu ausgefeilten Techniken wie dem Zurückrechnen der PIN aus den Daten des Beschleuni-gungssensors [3] oder der Kamera [4].

Dabei sind nicht alle Angriffe auf allen Smartphone-Plattfor-men gleich wahrscheinlich – Android weist sicher nach wie vor die höchste Verwundbarkeit gegen Angriffe auf Anwendungsebe-ne auf, doch einen wirklichen Schutz gegen das Sniffen der PIN bietet derzeit keine Plattform. Dabei wären technisch adäquate Lösungen möglich: Sowohl aktuelle Intel-, als auch ARM-Pro-zessoren verfügen über die Möglichkeit, sog. Trusted Execution Environments (TEE) [5] bereitzustellen. Durch das Umschalten des Prozessors in einen „Secure Mode“ ist es möglich, die Aus-führung des normalen Betriebssystems („Rich OS“) von der ei-nes minimalen sicheren „Trusted OS“ zu trennen. Dieses ist ver-gleichbar mit einer Smartcard, hat aber den Vorteil dass es auf dem normalen Prozessor läuft und damit zum einen sehr perfor-mant ist, und zum anderen auf die Peripheriegeräte wie z.B. den Touchscreen zugreifen kann. Liefe eine PIN-Abfrage innerhalb eines solchen TEE ab, so wäre sie gegen Angriffe durch bösartige Apps geschützt, da diese vollständig von der Ausführung im TEE isoliert sind. Ein Benutzer könnte dann z.B. durch eine speziel-le Hintergrundeleuchtung oder andere Hardware, die nur durch das TEE angesprochen werden kann unterscheiden, ob es sich um ein „sicheres“ oder eine normales On-Screen-Keyboard handelt.

Doch während die meisten handelsüblichen Prozessoren einen Secure Mode unterstützen, fehlt es noch an der Verbreitung von frei nutzbaren TEE-Betriebssystemen. Eines dieser Betriebssys-teme ist in der aktuellen Samsung-Galaxy Baureihe vorhanden. Doch ähnlich wie bei Secure Elements muss der Payment-An-bieter mit dem Betreiber der Plattform zusammenarbeiten, um das TEE nutzen zu können und die Bandbreite der unterstützten Smartphones ist beschränkt.

DuD • Datenschutz und Datensicherheit 1 | 2014 23

SCHWERPUNKT

7 Fazit

Festzuhalten bleibt: Mobile Payment wird die Kreditkarte auf absehbare Zeit nicht ersetzen, doch sicher zu einem etablierten Bezahlverfahren werden. Dass NFC selbst keinerlei Sicherheits-funktionen bietet, stellt noch kein Problem dar, sondern verla-gert die Sicherheitsmaßnahmen auf die Anwendungsebene. Hier bleibt jedoch abzuwarten, inwieweit die Anbieter in der Lage sein werden, adäquate Sicherheitsarchitekturen aufzusetzen. Dies ist durchaus nicht trivial, zumal es noch wenige Referenzarchitek-turen und Erfahrungswerte gibt und verschiedenste Sicherheits-technologien unter einen Hut gebracht werden müssen, die je-weils für sich genommen schon einen hohen organisatorischen und technischen Aufwand bedeuten.Anbieter, die jetzt die Entwicklung mobiler Bezahllösungen an-streben, sind daher gut beraten, sich von vorneherein Gedanken über eine zukunftsfähige Sicherheitsarchitektur zu machen, da

sich der Erfolg von Bezahlverfahren nicht zuletzt beim Kriteri-um Sicherheit entscheidet.

Literatur[1] Henning Siitonen Kortvedt and Stig F. Mjølsnes. Eavesdropping Near Field

Communication. The Norwegian Information Security Conference (NISK) 2009

[2] Roland, M.. Applying recent secure element relay attack scenarios to the real world: Google Wallet Relay Attack. Technical Report. NFC Research Lab Hagenberg

[3] Cai, L., & Chen, H.. TouchLogger: inferring keystrokes on touch screen from smartphone motion. In HotSec’11 Proceedings of the 6th USENIX confe-rence on Hot topics in security, 2011

[4] Simon, L., & Anderson, R.. PIN Skimmer: Inferring PINs Through The Came-ra and Microphone. Proceedings of the 3rd Annual ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM), 2013, 67–78.

[5] Global Platform, “TEE Client API Specification v1.0.” 2010.

Manfred Jürgen Matschke, Gerrit BröselUnternehmensbewertungFunktionen — Methoden — Grundsätze

4., vollst. überarb. Aufl . 2013. LIV, 897 S. mit 334 Abb. Geb. € (D) 49,95ISBN 978-3-8349-4052-0Umfassend, kompetent und aktuell präsentiert dieses Lehrbuch die funktionale Unter-nehmensbewertung. Alle wichtigen Bewertungsmethoden werden auf ihre Eignung ge-prüft und der relevanten Funktion der Unternehmensbewertung zugeordnet. Um die Transparenz der Unternehmenswertermittlung zu erhöhen, wird der Bewertungsprozeß in drei Schritte zerlegt: 1. Beschaffung der Informationen, 2. deren Transformation in den gesuchten Wert sowie 3. Verwendung dieses Wertes. Die Unternehmensbewertung wird dabei nicht nur für Kauf und Verkauf, sondern explizit auch für Fusion und Spaltung analysiert.

Umfassendes und aktuelles Kompendium für Studium und Praxis

springer-gabler.de

Änd

erun

gen

vorb

ehal

ten.

Erh

ältli

ch im

Buc

hhan

del

od

er b

eim

Ver

lag.

Einfach bestellen: SpringerDE-service@springer.com Telefon +49 (0)6221 / 3 45 – 4301

24 DuD • Datenschutz und Datensicherheit 1 | 2014

SCHWERPUNKT