PSD2 und die Sicherheit von Mobile-Banking

Die EU-Richtlinie PSD2 vom Oktober 2015 legt die Sicherheitsstandards für Online-Banking und Online-Payments neu fest. Auf die PSD2-Anforderung nach zwei Authentisierungs-Faktoren sind die deutschen Banken mit ihren TAN-Verfahren schon seit geraumer Zeit gut vorbereitet. Allerdings könnte die neue, zusätzliche PSD2-Anforderung, dass diese zwei Faktoren voneinander unabhängig sein müssen, den Banken Probleme bereiten, und zwar für das immer populärer werdende Mobile-Banking – also auf Smartphone und Tablet. Das Problem: Smartphone-Trojaner.

von Dr. Bernd Borchert, Informatik.Institut, Uni Tübingen

Muss wegen Smartphone-Trojanern beim Mobile-Banking die Unabhängigkeit der zwei Faktoren aufgegeben werden? Zwei Faktoren sind nur dann gegeben, wenn einer der beiden Faktoren von außerhalb des Smartphones kommt.Das hieße, dass für Mobile-Banking die Idee von „Mobilität“ zu einem wesentlichen Teil aufgegeben werden müsste, nämlich in dem Sinne, dass der Bankkunde ein extra Gerät dabei haben müsste. Das scheint wenig praktikabel.

Im Oktober 2015 ist die neue Zahlungs­dienst­leisterrichtli­nie PSD2 („Payment Service Directive 2“) herausgekommen. Die­se EU-Richtli­nie mit Geset­ze­scha­rak­ter muss bis 2018 natio­nal umgesetzt wer­den. PSD2 [1] regelt sehr viele Aspekte des Zahlungsverkehrs. Wir wollen die Vorschriften beleuchten, die die Sicherheit von Online-Banking und Online-Zahlungen betreffen, insbesondere die von Mobile-Banking, also Online-Banking auf dem Smartphone und Tablet. Die schon seit Januar 2016 geltenden MaSI-Bestimmungen [2] der BaFin haben praktisch die gleichen Anforderungen an die Kundenauthentisierung – Mobile-Banking/Payment ist aber explizit (Art. I/11.) von MaSI ausgenommen.

Zwei von drei Faktoren: Haben, Sein und Wissen

PSD2 verlangt für Online-Überweisungen/Zahlungen eine „starke Kundenauthentisierung“, und zwar zwei Faktoren (=Elemente) aus den drei Kategorien Wissen (z.B. Passwort), Haben (= Besitz, z.B. TAN-Generator) und Sein (= Inhärenz = Biometrie, z.B. Fingerprint). Beispielsweise erfüllt das Flackercode-Verfahren („Chip-TAN“) die 2-Faktor Anforderung, denn eine Überweisung ist mit dem Einlogg-Passwort (Faktor Wissen) und der in dem Flackercodegerät steckenden Scheckkarte (Faktor Haben) geschützt. Auch SMS-TAN erfüllt die 2-Faktor-Anforderung: neben dem Einlogg-Passwort kommt hier die SIM-Karte als Faktor Haben ins Spiel. Bei App-TAN Verfahren wie PushTAN oder PhotoTAN/App stellt neben dem Einlogg-Passwort das Smartphone – genauer gesagt: der darauf gespeicherte geheime Schlüssel – den Faktor Haben dar.

TAN- und iTAN nicht PSD2-Konform

Das TAN- und das iTAN Verfahren sind zwar Verfahren mit jeweils 2 voneinander unabhängigen Faktoren, aber sind dennoch nicht PSD2-konform: das liegt an einer weiteren Anforderung in Art. 97 (2) der PSD2, die verlangt, dass die Überweisungsdaten in die Generierung der TAN eingehen – als Schutz vor Man-in-the-Middle-Angriffen durch Trojaner auf dem Endgerät, die dem Bankkunden anstatt der von ihm eingegebenen Überweisung eine Betrugsüberweisung unterjubeln, ohne dass er etwas bemerkt, d.h., ohne dass er etwas falsch macht.

PSD2 verlangt allerdings nicht nur 2 Faktoren, sondern diese müssen auch voneinander unabhängig sein, siehe die Definition in der Textbox. Beim Flackercode-Verfahren sind die 2 Faktoren zweifellos voneinander unabhängig, auch wenn das Passwort auf dem Endgerät durch Trojaner abgehört werden könnte. Bei Online-Banking am PC/Laptop mit SMS-TAN oder mit App-TAN kann zwar der eine Faktor durch einen PC-Trojaner und der andere durch einen Smartphone-Trojaner erfolgreich angegriffen werden, aber eine Synchronisierung der beiden Trojaner ist praktisch nicht möglich, deshalb kann die Unabhängigkeit der zwei Faktoren als gegeben angesehen werden.

Mobile-Banking / Online-Banking – eine andere Situation

Beim Mobile-Banking, d.h., Online-Banking auf dem Smartphone oder Tablet, ist die Situation anders. Schon 2009 haben die deutschen Banken in einem gemeinsamen Beschluss SMS-TAN untersagt, wenn das Online-Banking-Endgerät das gleiche Gerät ist, welches die SMS empfängt – mit der Begründung, dass die Kommunikationskanäle für die Dateneingabe und für die SMS nicht vollständig voneinander getrennt sind (Anforderung “Kanaltrennung“) [3].

Die Banken, die App-TAN Mobile-Banking einsetzen, argumentieren, dass mit zwei verschiedenen Apps (Banking-App und TAN-App) zwei getrennte Kanäle vorhanden seien, App-TAN also das Kanaltrennungsprinzip erfülle. Mit PSD2 ist aber nicht mehr „Kanaltrennung“ das Thema, sondern die Unabhängigkeit der 2 Faktoren. Im Folgenden wird argumentiert, das bei App-TAN Mobile-Banking die beiden Faktoren nicht unabhängig sind.

Mit App-TAN beim Mobile-Banking ist der Angriff für einen Trojaner – wenn er erst einmal in das Betriebssystem des Smartphones eingedrungen ist – einfach, siehe Kasten. Bei diesem Angriff hört der gleiche Trojaner (1) das Passwort ab und (2) kopiert den geheimen Schlüssel. Mit anderen Worten: Die Sicherheit, die durch das Passwort gegeben ist, und die Sicherheit, die durch den geheimen Schlüssel gegeben ist, sind nicht voneinander unabhängig, denn mit dem einen ist das andere auch gebrochen. Das ist ein Widerspruch zur geforderten Unabhängigkeit der zwei Faktoren in der Definition von „starke Kundenauthentifizierung“, (siehe oben). Mit anderen Worten: App-TAN Mobile-Banking ist nicht PSD2-konform. Dieses Problem mit App-TAN beim Mobile-Banking ist in der EBA-Diskussion zu PSD2 als Problem 32 beschrieben.

Dass bei SMS-TAN Mobile-Banking die zwei Faktoren ebenfalls nicht voneinander unabhängig sind, liegt an einem Trojaner-Angriff, der rechts in der Textbox beschrieben ist.
Insgesamt sieht also die Situation für Mobile-Banking schlecht aus: iTAN ist sowieso nicht PSD2-konform, und SMS-TAN und App-TAN widersprechen der PSD2-Unabhängigkeits-Anforderung.

Welche TAN-Verfahren kann eine europäische Bank für Mobile-Banking anbieten, ohne spätestens 2018 die Vorschriften von PSD2 zu verletzen?

Bleiben nur die TAN-Generatoren als Lösung? – die haben im Vergleich zu SMS-TAN und App-TAN große Nachteile: sie sind teuer (entweder die Bank oder der Kunde muss ihn zahlen), sie sind umständlich zu bedienen (z.B. Flackercodegerät), und – vor allem – sie nehmen Mobile-Banking etwas Wesentliches, nämlich einen Teil der Mobilität: der Kunde muss ein extra Gerät dabei haben.

Ist Smartphone-Biometrie die Lösung?

Neu an PSD2 war die Einführung von Biometrie als mögliche Authentisierungs-Kategorie, z.B. Fingerprint, oder Selfie per Smartphone-Kamera, oder Stimmerkennung. Viele Banken setzen deshalb ihre Hoffnung auf Smartphone-Biometrie, um so einen der zwei geforderten Sicherheits-Faktoren zu bekommen, vor allem für Mobile-Banking. Beispielsweise könnte der Fingerprint das Passwort ersetzen – die Bankkunden würden das schätzen.

Das kleinere von zwei PSD2-Problemen mit Smartphone-Biometrie ist, dass das biometrische Merkmal beim Bankserver geprüft werden müsste und nicht – wie beim iPhone Fingerprint – lokal auf dem Smartphone, denn eine lokale Prüfung wird wohl nicht als Faktor Sein gelten (z.B. gilt ein nur lokal auf dem Smartphone geprüftes Passwort nicht als Faktor Wissen). Bei der anderen Variante der Biometrie-Prüfung beim Bankserver käme eventuell noch eine langwierige Datenschutz-Diskussion ins Rollen – bei Fingerprint wie auch bei Selfies.

Das größere PSD2-Problem mit Smartphone-Biometrie ist aber die Unsicherheit hinsichtlich Smartphone-Trojanern: die biometrischen Daten könnten vom Trojaner einfach abgehört werden, siehe Kasten.

Beim Mobile-Banking-Szenario kann der Trojaner, der das biometrische Merkmal ausspioniert, der gleiche sein, der auch das Passwort bzw. den geheimen Schlüssel ausspioniert, je nachdem, was der andere Faktor ist. Das heißt, es liegt das gleiche Problem vor wie oben bei App-TAN beschrieben: mit dem einen Faktor ist auch der andere gebrochen, d.h., die zwei Faktoren sind nicht voneinander unabhängig. Zusammengefasst: auch mit Smartphone-Biometrie (egal welche) wird Mobile-Banking nicht PSD2-konform.

Es bringt natürlich auch nichts, alle 3 Smartphone-Faktoren Passwort, Biometrie und geheimer Schlüssel zusammenzuwerfen: laut Definition müssten zwei der drei Faktoren voneinander unabhängig sein – was aber für alle drei 2er-Kombinationen nicht der Fall ist.
Auch reaktive Biometrie, wie zum Beispiel Stimmerkennung mit immer anderen Texten, ist keine Lösung. Der Trojaner erstellt sich anstatt einer Kopie des biometrischen Merkmals eine Charakteristik des biometrischen Merkmals und täuscht damit dem Bankserver vor, der Bankkunde zu sein. Um beispielsweise Stimmerkennung zu brechen, gibt es schon seit 2001 „voice cloning“ [4].

Ist das Secure Element eine Lösung?

Ein Lösungsvorschlag für Online- und Mobile-Banking, der schon seit Jahren diskutiert wird, besteht darin, den geheimen Schlüssel für App-TAN in einem Secure Element im Smartphone zu speichern, um ihn so vor dem Ausspionieren durch Smartphone-Trojaner zu verstecken, beispielsweise könnte die SIM-Karte dieses Secure Element darstellen. Ganz abgesehen von dem großen Aufwand, den das Bereitstellen der Infrastruktur („Trust Centers“ zusammen mit den Telefonunternehmen etc.) dafür erfordern würde, hat diese Lösung beim Mobile-Banking ein fundamentales Sicherheitsproblem: der geheime Schlüssel kann zwar nicht vom Trojaner kopiert, aber von ihm heimlich „missbraucht“ werden kann, siehe Kasten.

Der heimliche Missbrauch des geheimen Schlüssels im Secure Element stellt beim Mobile-Banking eine Kompromittierung des Faktors Haben durch den Trojaner dar. Faktor Haben und Faktor Wissen sind also nicht unabhängig, denn sie können beide vom gleichen Trojaner gebrochen werden. Das bedeutet: die Verlagerung des Schlüssels in ein Secure Element im Smartphone macht App-TAN Mobile-Banking nicht PSD2-konform.

Software-Lösungen oder nur partiell hardware-unterstützte Lösungen für ein Secure Element wie iPhone Keychain, Trusted Zones, etc. haben natürlich das gleiche Problem, denn der oben beschriebene Missbrauchs-Angriff ist analog durchführbar (ganz abgesehen davon, dass es bei einer Softwarelösung immer zweifelhaft ist, ob sie nicht doch vom Trojaner infiltriert werden kann).

Gibt es diese gefährlichen Smartphone-Trojaner wirklich?

Das Smartphone ist ein Computer, und zwar ein universeller Computer in dem Sinne, dass Programme für ihn geschrieben werden können und dabei das Betriebssystem selber ein ausführbares Programm ist. Ein solcher Computer ist grundsätzlich infiltrierbar, insbesondere das Betriebssystem.

Smartphones werden als sicherer angesehen als PCs. Das liegt an der „Sandbox“-Architektur: jede App hat nur den Zugriff auf die eigenen Daten, d.h., eine App kann die Daten der anderen nicht lesen, geschweige denn manipulieren. Die Sandbox-Architektur wird vom Betriebssystem bereitgestellt, das heißt, sie gilt nur für die Apps, nicht für das Betriebssystem selber. Das Betriebssystem ist also das wirklich interessante Ziel eines Angreifers: wenn das Betriebssystem infiltriert ist, können alle Apps zur Laufzeit abgehört und manipuliert werden.

Dass es für jedes Smartphone-Betriebssystem Trojaner gibt, die es im Kern infiltriert haben, ist unbestritten. Die Frage ist, ob ein Angreifer bei einem regulären, d.h. vom Benutzer nicht „gerooteten“ Smartphone überhaupt soweit kommen kann. Die Antwort ist „ja“: Bislang gab es – für teures Geld auf dem Schwarzmarkt[5] – bei jeder neuen Version von iOS oder Android Software-Baukästen, die eingebaut in eine auf dem App-Store verfügbare App und von da downgeloaded auf ein reguläres Smartphone, auf dem Smartphone beim Aufruf heimlich den Kern für einen Betriebssystem-Trojaner installieren konnten (der Rest wird heimlich per Internet nachgeladen).

Die Bank-App könnte versuchen herauszufinden, ob das Betriebssystem infiltiert ist. Weil eine App aber nur wenige Rechte hat, hat sie gegen das mächtige Betriebssystem keine Chance: das infiltrierte Betriebssystem wird direkte und indirekte Anfragen der App immer so beantworten, dass es so aussieht, als sei alles ok. Wenn beispielsweise die App das Betriebssystem fragt „Ist das Betriebssystem infiltriert?“, wird das infiltrierte Betriebssystem antworten: „Nein“.

Banken haben nach eigenen Angaben bislang nur ganz wenige erfolgreiche Angriffe von Smartphone-Trojanern auf SMS-TAN und App-TAN zu verzeichnen. Es könnte aber nur eine Frage der Zeit und der kritischen Masse sein, bis die Angreifer sich auf die Smartphones und Tablets konzentrieren.

Eine „Fake-App“ ist eine App, die so aussieht wie eine reguläre App, z.B. von der Bank, die aber vom Betrüger geschrieben und mit Hintertüren versehen ist. Sie gelangt mit Vorwänden auf das Smartphone des Bankkunden. Die Fake-App hört Passwort und geheimen Schlüssel ab und schickt sie heimlich weiter oder führt mit diesen Informationen heimlich selber per Internet Betrugsüberweisungen aus. Alle in diesem Artikel beschriebenen Betriebssystem-Trojaner-Angriffe können auch von Fake-Apps ausgeführt werden. Die Fake-Apps stellen somit neben den Betriebssystem-Trojanern eine zweite Gefahr für Online/Mobile-Banking dar. Fake-Apps könnten die größere Gefahr sein, denn sie sind einfacher zu schreiben als Betriebssystem-Trojaner.

Ignorieren der PSD2-Vorschriften als Lösung?

Es scheint keine PSD2-konforme Lösung für Mobile-Banking zu geben, die ohne extra Gerät auskommt, denn alle auf dem Smartphone abgefragten Faktoren sind durch einen Smartphone-Trojaner kompromittierbar, d.h., wenn mehr als ein Faktor auf dem Smartphone abgefragt wird, sind diese schon nicht mehr unabhängig voneinander. Mit anderen Worten: nur ein Faktor kann auf dem Smartphone abgefragt werden, der andere muss „von außen“ kommen, z.B. von einem TAN-Generator.

Eine Bank könnte auf die noch festzulegenden nationalen Regelungen für Kleinbeträge hoffen. Zwar liegt die offizielle Kleinbetragsgrenze, für die keine starke Authentisierung verlangt wird, bei nur 30 Euro (PSD2, Art. 63), aber national könnte der Betrag auf 60 Euro hochgesetzt werden. Damit wäre schon für einen Teil aller Überweisungen und Payments eine App-TAN oder SMS-TAN Mobile-Banking-Überweisung auf dem Smartphone PSD2-konform möglich. Wer höhere Beträge überweisen will, kann das nicht mobil tun, sondern muss an einen PC gehen, oder muss einen TAN-Generator einsetzen.

Erfüllen oder für Schäden der Kunden zahlen

Eine andere Möglichkeit für die Bank wäre es, die PSD2 Authentisierungs-Anforderungen komplett zu ignorieren. Das ist bei PSD2 sogar implizit vorgesehen, nur muss die Bank dann alle Schäden selber übernehmen, das ist in Art. 74(2) so geregelt. Es gilt also bei PSD2 nicht mehr „comply or explain“ wie bislang bei BaFin-Bestimmungen, sondern es gilt „comply or pay (the damage compensation)“. Falls eine Bank schon jetzt App-TAN einsetzt und es auch weiterhin wenig Schäden gibt, könnte die Ignorierung der Anforderungen eine Lösung für Mobile-Banking sein – eine pragmatische Lösung, aber keine, die bei den Kunden besonders vertrauenserweckend wäre.

Eine weitere Möglichkeit wäre es, die Unabhängigkeits-Anforderung in der Definition von „starke Kundenauthentisierung“ als „Sollte“- und nicht als „Muss“-Anforderung zu interpretieren. Beispielsweise ist die letzte Anforderung „Vertraulichkeit der Authentifizierungsdaten ist geschützt“ offenbar tendenziell eine Sollte-Anforderung, denn bei praktisch allen Online-Banking-Verfahren wird das Passwort auf einem unsicheren Gerät eingegeben und ist somit nicht vollständig geschützt. Der Unterschied ist allerdings, dass die Nichterfüllung dieser Vertraulichkeits-Anforderung nur mit geringster Wahrscheinlichkeit zu Betrugsschäden führt, denn der andere Faktor ist ungebrochen, während die Nichterfüllung der Unabhängigkeits-Anforderung direkt zu Schäden führt.

Alle Überlegungen in diesem Artikel sollten nicht nur für Mobile-Banking, d.h. für auf dem Smartphone/Tablet durchgeführte Bankkonto-Überweisungen, sondern auch – bis auf die in PSD2, Art. 3 genannten Ausnahmen – für auf dem Smartphone/Tablet durchgeführte Internet-Payments gelten, also insbesondere für auf dem Smartphone/Tablet durchgeführte Kreditkartenzahlungen.

Zusammenfassung

Die Authentisierungs-Anforderungen der ab 2018 geltenden PSD2-Richtlinie erfordern für Mobile-Banking einen extra TAN-Generator zusätzlich zum Smartphone, auch biometrische Verfahren oder Secure Elements auf dem Smartphone können daran nichts ändern. Grund dafür ist die Unabhängigkeits-Anforderung an die 2 Faktoren, die wegen Smartphone-Trojanern allein auf dem Smartphone nicht zu erfüllen ist. Die Banken müssten den Bankkunden für Mobile-Banking also einen extra TAN-Generator zur Verfügung stellen, oder sie müssten für Überweisungen, die über 60 Euro hinausgehen, den Bankkunden auffordern, an einen PC zu gehen, oder sie müssten die PSD2-Anforderungen ignorieren und dafür alle Betrugsschäden selber übernehmen.aj

Links:
[1] PSD2
[2] MaSI
[3] SMS-TAN für Mobile Banking nicht erlaubt
[4] Voice cloning
[5] Preise von exploits

Dieser Artikel ist eine deutschsprachige, überarbeitete Version des Beitrags des Autors auf der Webseite der EBA zur Diskussion der PSD2-Richtlinie vom Februar 2016, siehe Beitrag mit Überschrift „Univ. Tuebingen, Wilhelm-Schickard-Institut fuer Informatik“.