PSD2: Vom Artikel 9 der RTS zur abgesicherten Ausführungsumgebung für mobile Banking-Apps

Die überarbeitete Payment Service Directive 2, auch bekannt als PSD2, fokussiert die Sicherheit mobiler Banking-Apps, mobiler Payment-Apps, Mobile-Wallets und anderer Apps, die über eine Zahlungsfunktion verfügen. Die wichtigsten Anforderungen im Zusammenhang mit der Sicherheit mobiler Apps sind in Artikel 9 der abschließenden technischen Regulierungsstandards (RTS) zur starken Kundenauthentifizierung (SCA) und zur gemeinsamen und sicheren Kommunikation (CSC), einem Nachtrag zu PSD2, enthalten.

Dieser Artikel fordert von Banken, welche Mobilgeräte zur Authentifizierung von Zahlern oder Transaktionen verwenden, „die Risiken, die von kompromittierten Geräten ausgehen können, zu minimieren“. Der Artikel listet eine Reihe von schadensbegrenzenden Maßnahmen auf, die von den Banken angewendet werden sollten, darunter die „Verwendung einer separaten, gesicherten Laufzeitumgebung (Secure Execution Environment, kurz SEE)“ auf dem mobilen Gerät sowie Mechanismen zur Erkennung und Abwehr von Veränderungen des Gerätes selbst.

Im endgültigen RTS sind die Maßnahmen zur Schadensbegrenzung allerdings nur sehr vage gehalten. Dennoch gelten sie für Mobile-Banking-Apps sowie Apps mit Zahlungsfunktionalität, da der Authentifizierungsmechanismus dieser Applikationen ja auf dem Mobilgerät basiert. Daraus ergibt sich zwingend, dass Mobile-Banking-Apps innerhalb sicherer Laufzeitumgebungen ausgeführt werden und vor einer Veränderung ihrer Funktionalität geschützt werden müssen.

Aber wie sieht eine sichere Laufzeitumgebung aus?

Das Fehlen jeglicher Details erschwert Finanzinstituten eine zukunftssichere, technologie-unabhängige Implementation der Schutzmaßnahmen. Gleichzeitig wird den zuständigen nationalen Behörden die Möglichkeit genommen, die getroffenen Maßnahmen zum Schutz mobiler Applikationen im Zahlungsverkehr dahingehend zu bewerten, ob sie den Anforderungen der endgültigen RTS genügen. 

Eine Definition, was eine gesicherte Laufzeitumgebung ist, hilft hier weiter. Versuchen wir daher zunächst eine nützliche Definition für SEE zu finden. In der Welt des vertrauenswürdigen Computing wird SEE typischerweise als eine integritätsgeschützte Verarbeitungsumgebung definiert, die gesicherte Möglichkeiten zur Verarbeitung, Speicherung und Aufbewahrung bietet. Somit ist die SEE von der „normalen“ Verarbeitungsumgebung des mobilen Geräts isoliert und stellt sicher, dass mobile Apps ohne Beeinträchtigung durch andere Prozesse oder Programme (z. B. Malware), die sich ebenfalls auf dem Gerät befinden, ausgeführt werden können. Solche SEEs können mithilfe von Hardwarearchitekturen wie ARM TrustZone oder auf der Grundlage der TEE-Spezifikation (Trusted Execution Environment) von GlobalPlatform realisiert werden. Allerdings werden solche hardwarebasierten Sicherheitsarchitekturen nur selten eingesetzt.

Glücklicherweise erlaubt die Definition von SEE im RTS eindeutig SEEs, die nicht auf Hardware-Sicherheitsmechanismen angewiesen sind. Tatsächlich wurde in einer frühen Entwurfsversion des RTS festgelegt, dass die „sichere Ausführungsumgebung“ unter Verwendung von reinen Software-Sicherheitsmechanismen aufgebaut werden kann und dass sie nicht auf hardwarebasierten Sicherheitsmechanismen beruhen muss. Frühere Versionen des RTS verwendeten den Ausdruck „Trusted Execution Environment“ statt „Secure Execution Environment“, dies wurde jedoch geändert um zu betonen, dass auch Mechanismen die nicht explizit auf Hardware beruhen, die Anforderungen erfüllen.

Eine pragmatischere Definition von SEE könnte daher wie folgt aussehen: SEE ist eine Ausführungsumgebung, die Schutz vor bekannten Angriffen auf mobile Apps bietet. Dieser Ansatz befasst sich mit Attacken, mit denen Banken heute üblicherweise rechnen müssen und definiert eine Ausführungsumgebung als sicher, wenn sie einen angemessenen Schutz gegen diese bietet. Als Folge daraus wird sich die Definition einer sicheren Ausführungsumgebung im Laufe der Zeit weiterentwickeln, analog zur Entwicklung der Bedrohungslandschaft für mobile Banking-Apps.

Aktuell gibt es eine ganze Reihe von Sicherheitsbedrohungen für mobile Banking-Apps:

• Overlay-Angriffe, bei denen Malware auf dem Mobilgerät ein Fenster über der echten Banking-App anzeigt, das der Banking-App sehr ähnlich ist. Auf diese Weise versucht die Malware sensitive Informationen wie Benutzername oder PIN des Users abzugreifen. Bekannte Vertreter dieser Art von Malware sind Marcher und BankBot. 

• Code-Injection oder Hooking sind Angriffe, bei denen mittels Malware die Funktionalität einer Mobile-Banking-App verändert werden soll. Zum Beispiel könnte die App modifiziert werden, um den PIN-Code des Benutzers auszulesen oder finanzielle Transaktionen heimlich umzuleiten. Betrüger können dabei auf Hooking-Frameworks wie Frida und Xposed zurückgreifen.

• Keylogging, bei der Malware auf dem mobilen Gerät Tastenanschläge oder Gesten abfängt, um vertrauliche Daten wie PINs zu stehlen.

• Auch das Abfangen von SMS-Nachrichten die Authentifizierungscodes enthalten, ist heutzutage eine beliebte Spielform vieler Android-Malware-Familien.

Und wie erstelle ich jetzt eine sichere Ausführungsumgebung?

Um eine sichere Ausführungsumgebung für Mobile-Banking-Apps zu schaffen, empfiehlt es sich, sie mit Application-Shielding-Technologie zu schützen, die auch als Runtime Application Self-Protection (RASP) bezeichnet wird. Diese Technologie schützt eine mobile App vor verschiedenen Arten von Laufzeitbedrohungen durch die Erstellung einer sicheren virtuellen Ausführungsumgebung, so dass diese auch auf nicht vertrauenswürdigen mobilen Geräten ausgeführt werden kann.

Application-Shielding schützt mobile Apps durch eine Kombination aus präventiven, detektivistischen und reaktiven Ansätzen. Es verhindert Laufzeitbedrohungen, zum Beispiel durch Verschleiern von Code, um Reverse Engineering zu erschweren. Es erkennt Angriffe während der Ausführung, z. B. Versuche, die App zu manipulieren oder die App in einem Emulator zu starten. Schließlich kann es auf verschiedene Arten auf Laufzeitangriffe reagieren, beispielsweise indem es die serverseitigen Risikoengines der Bank alarmiert oder sogar die App herunterfährt.

www.onespan.com 

Von Frederik Mennes, Senior Manager Market & Security Strategy OneSpan (vormals VASCO)