Mobile Banking und PSD2: Ist die Bankenindustrie vorbereitet?

Seit die neu überarbeitete EU-Zahlungsdienstrichtlinie PSD2 am 13. Januar 2018 in Kraft getreten ist, steht sowohl die Banken- als auch die Cybersicherheitsbranche vor großen Veränderungen.

Denn die PSD2 sieht es vor, dass Bankkunden ihre Finanzverwaltung fortan auch über Drittanbieter wie Fintechs oder Non-Banking-Lösungen wie Social Media abwickeln können, ohne dafür Geld von ihren ursprünglichen Konten transferieren zu müssen.

Obwohl mobile Betriebssysteme die Verknüpfung von Anwendungen aus Gründen der Datenschutz-Gewährleistung gerne aktiv verhindern, sind Banken dann verpflichtet, offene Programmierschnittstellen (APIs) bereitzustellen, um Drittanbietern einen komplikationslosen Zugriff auf die Konten ihrer Kunden zu ermöglichen. Sowohl Finanzdienstleister als auch Bankkunden sehen sich mit neuen Risiken konfrontiert.

APIs in der Finanzwelt: Fehlende Standards & Sicherheitsrisiken

Der großflächige Einsatz von Application Programming Interfaces kurz APIs ist eine wesentliche Voraussatzung für die Öffnung des Zahlungsmarktes für Drittanbieter und bis heute leider auch ein Hemmnis. Denn nicht alle Finanzinstitute stellen mittlerweile APIs zur Verfügung. Und die, die es tun, veröffentlichen teilweise verschiedene und uneinheitliche Sets von APIs.

Dies hat zur Folge, dass die Art und Weise, wie jede Bank Kundendaten kommuniziert und authentifiziert, sehr unterschiedlich sein kann. Je nachdem bei welcher Bank sich das Konto des Kunden befindet, müsste die Drittanbieter-App möglicherweise eine andere API einsetzen, um auf die Daten dieses Kontos zugreifen zu können. Für Drittanbieter, App-Entwickler wie Endnutzer bedeutet diese Inkonsistenz folglich einige Komplikationen.

Viel problematischer als das Fehlen von Standards sind jedoch die mit der Nutzung von APIs verbundenen Sicherheitsrisiken. Denn bei all der Praktikabilität und Bequemlichkeit darf man nicht übersehen, dass APIs auch eine Reihe von Risiken mit sich bringen. Besonders sicherheitskritisch ist dabei der Einsatz einfacher Authentifikation.

Diese wird von vielen API-Management-Lösungen genutzt, um zu bestätigen, dass die Client-App auf einem Gerät echt ist und auf einen Server zugreifen darf. Dies geschieht typischerweise über einen einfachen Challenge-Response-Austausch, da die Client-Anwendung versucht, sich mit dem API-Server zu verbinden. Dabei handelt es sich meist um einen kryptographischen Vorgang, bei dem der mobile Client einen geheimen Schlüssel für eine asymmetrische Chiffre wie RSA oder ECC enthält. Hier können Cyberkriminelle nun angreifen.

Alles, was sie dafür tun müssen, ist eine beliebige Applikation in einer Sandbox-Umgebung zu isolieren und wiederholt so zu bearbeiten, bis sie einen Weg gefunden haben, Sicherheitsbarrieren zu umgehen.

Nach dem Knacken der Anwendung verschaffen sich die Angreifer in einem zweiten Schritt Zugriff auf die APIs und täuschen einen legitimen Client vor, um auf diese Weise Zugang zu allem, wofür die API autorisiert wurde, zu erlangen. So könnte eine API die auf den Backend-Server einer Bank-Anwendung Zugriff hat, dazu genutzt werden, sensible personenbezogene Kontodaten abzugreifen oder andere schädliche Aktivitäten z.B. Transaktionsmanipulationen auszuführen.

Effektive Cybersecurity-Strategien sind für Banken in Zeiten der digitalen Transformation und Angesichts eines lebendigen Wettbewerbsmarktes wichtiger denn je. Zuverlässige Online-Banking-Verfahren, risikoarme TAN-Generierung und nicht zuletzt sichere mobile Banking-Apps haben im Finanzwesen deshalb mittlerweile höchste Priorität. Viele Banken haben ihre Sicherheitsmaßnahmen in den letzten Jahren stark ausgebaut, wenngleich vor allem im Bereich Mobile noch Luft nach oben ist, wie Forscher der Uni Erlangen anhand von 31 lückenhaften Banking-Apps Ende November wieder einmal gezeigt haben.

Noch schlechter ist die Situation indes bei den Anwendungen der Drittanbieter, die die erst seit kurzem auf den Parkett des Finanzmarktes drängen. Ihr Nachholbedarf in Sachen Sicherheit dürfte deutlich größer sein. Immerhin unterliegt die Mehrheit dieser Applikationen längst nicht denselben strengen Regularien wie die Banking-Apps, insbesondere hinsichtlich des Speicherorts und der Zugriffsmöglichkeit auf die Daten. Wenn die Bankenanwendungen jedoch verpflichtet werden sollen, APIs für Apps von Drittanbietern bereitzustellen, ist ein einheitlicher Sicherheitsstandard unabdingbar.

PSD2 rückt App-Härtung in den Vordergrund

Das Gute an PSD2 ist, dass mit der Öffnung des Zahlungsmarktes für Drittanbieter dem Thema Applikationshärtung endlich mehr Aufmerksamkeit zukommt. Denn in sich geschützte Apps sind jetzt wichtiger denn je. Anstatt die Anwendungsumgebung zu schützen und quasi einen Zaun um die Applikation zu bauen, muss die App selbst geschützt werden, wenn Banken und Bankkunden von Manipulationen und Betrug sicher sein und einen risikolosen Datenaustausch gewährleisten wollen.

Um Cyberangriffe dieser Art zu verhindern, bleibt den Entwicklern deshalb kaum eine andere Möglichkeit, als ihre Software am Ende des Entwicklungsprozesses mit innovativen Applikationshärtungs-Technologien auszustatten, die einen Diebstahl der Schlüssel und ein Reverse Engineering der Anwendung aktiv unterbinden. Möglich wäre hier etwa der Einsatz einer Obfuscation-Technik, das heißt einem Verschleierungsprozess, bei dem Code in unbrauchbares Scramble verwandelt wird, Code-Encryption-Maßnahmen oder eine Debugger-Detection, die selbstständig erkennt, ob eine Anwendung in einer Debugging-Umgebung gestartet wurde, die von Hackern verwendet wird.

Die neue Zahlungsdienstrichtlinie PSD2 bedeutet für Banken wie Drittanbieter neue Herausforderungen, bietet ihnen aber gleichzeitig die Chance, sich im wachsenden Wettbewerbsmarkt als verlässlicher und insbesondere sicherer Banking-Anbieter zu positionieren. Ich bleibe gespannt, wie die Umsetzung der neuen Richtlinie klappt.