PSD2: Erstellen einer sicheren Ausführungsumgebung für Mobile Banking-Apps
Die überarbeitete Richtlinie über Zahlungsdienste, auch als PSD2 bekannt, widmet der Sicherheit von Mobile-Banking-Apps, Mobile-Payment-Apps, Mobile-Wallets und anderen Apps, die Zahlungsfunktionen bieten, große Aufmerksamkeit.
Die wichtigsten Anforderungen bezogen sich auf Sicherheit für mobile Apps sind in Artikel 9 der endgültigen technischen Regulierungsstandards (RTS) für starke Kundenauthentifizierung (SCA) und gemeinsame und sichere Kommunikation (CSC) enthalten, einem Nachtrag zu PSD2. Dieser Artikel verlangt von Finanzinstituten (FIs), die mobile Geräte zur Authentifizierung des Zahlers oder von Finanztransaktionen verwenden, um „die Risiken zu mindern, die sich aus der Gefährdung des mobilen Geräts ergeben“. Der Artikel listet eine Reihe mildernder Maßnahmen auf, die FIs ergreifen sollten, einschließlich der „Verwendung getrennter sicherer Ausführungsumgebungen“ auf dem mobilen Gerät sowie Mechanismen zur Erkennung und Abwehr von Änderungen des mobilen Geräts.
Diese mildernden Maßnahmen im endgültigen RTS sind ziemlich vage. Sie gelten jedoch für Mobile-Banking-Apps und andere Apps mit Zahlungsfunktionalität, da der Authentifizierungsmechanismus solcher Apps vom mobilen Gerät abhängt. Infolgedessen müssen Mobile-Banking-Apps in sicheren Ausführungsumgebungen ausgeführt und vor Änderungen ihrer Funktionalität geschützt werden.
In diesem Artikel werden die Sicherheitsanforderungen für mobile Apps von PSD2 ausführlicher erläutert und erläutert, wie Banken sicherstellen können, dass ihre mobilen Apps diesen Anforderungen entsprechen.
Leiten
Unsichtbare Kanalsicherheit beim mobilen Banking
Laden Sie dies herunter leiten und lernen, wie Sie mehrschichtige Schutztechniken verwenden, Malware-Angriffe in Echtzeit identifizieren und blockieren, die biometrische Authentifizierung integrieren, die Authentifizierungskette von App zu Gerät stärken und die mobile App mit unsichtbarer Sicherheit schützen.
Jetzt herunterladenWas ist eine sichere Ausführungsumgebung?
Das endgültige RTS besagt, dass Finanzinstitute sichere Ausführungsumgebungen verwenden müssen, um mobile Apps zu schützen. Das endgültige RTS wird jedoch nicht definiert Was Eine sichere Ausführungsumgebung ist tatsächlich oder Wie es könnte implementiert werden. Das RTS bietet diesen Detaillierungsgrad nicht, um zukunftssicher und technologieunabhängig zu sein. Dies sind Gründe, die sinnvoll sind. Es lässt jedoch auch FIs, die in der Praxis eine sichere Ausführungsumgebung implementieren müssen, im Dunkeln darüber, wie eine solche Ausführungsumgebung aussehen sollte. In ähnlicher Weise bietet es den zuständigen nationalen Behörden nur begrenzte Leitlinien, die entscheiden müssen, ob der Ansatz eines bestimmten Finanzinstituts in Bezug auf die Sicherheit mobiler Apps tatsächlich den Anforderungen des endgültigen RTS entspricht.
Lassen Sie uns daher zunächst versuchen, eine nützliche Definition der „sicheren Ausführungsumgebung“ (SEE) zu finden. In der Welt des vertrauenswürdigen Rechnens wird ein SEE normalerweise als integritätsgeschützte Verarbeitungsumgebung definiert, die aus Verarbeitungs-, Speicher- und Speicherfunktionen besteht. Als solches ist die SEE von der „normalen“ Verarbeitungsumgebung des Mobilgeräts isoliert und stellt sicher, dass mobile Apps ohne Störung durch andere Prozesse oder mobile Apps (z. B. Malware) ausgeführt werden können, die sich auf demselben Gerät befinden.
Solche SEEs können mithilfe von Hardwarearchitekturen wie ARM TrustZone oder solchen basierend auf der TEE-Spezifikation (Trusted Execution Environment) von GlobalPlatform realisiert werden. Bis heute ist die Akzeptanz solcher hardwarebasierter Sicherheitsarchitekturen jedoch gering.
Die gute Nachricht ist, dass die Definition von SEE im RTS eindeutig SEEs ermöglicht, die nicht auf Hardware-Sicherheitsmechanismen angewiesen sind. In einem frühen Entwurf des RTS wurde festgestellt, dass die „sichere Ausführungsumgebung“ nur mit Software-Sicherheitsmechanismen erstellt werden kann und nicht auf hardwarebasierten Sicherheitsmechanismen basieren muss. Frühere Versionen des RTS verwendeten den Wortlaut "vertrauenswürdige Ausführungsumgebung" anstelle von "sichere Ausführungsumgebung". Dies wurde jedoch geändert, um zu betonen, dass auch Nicht-Hardware-Mechanismen ausreichen.
Eine pragmatischere Definition von SEE könnte daher wie folgt lauten: Ein SEE ist eine Ausführungsumgebung, die Schutz vor SEE bietet bekannte Angriffe gegen mobile Apps. Dieser Ansatz befasst sich mit Angriffen, denen Banken heute vor Ort ausgesetzt sind, und betrachtet eine Ausführungsumgebung als sicher, wenn sie einen angemessenen Schutz gegen diese Angriffe bietet. Daher ändert sich die Definition einer sicheren Ausführungsumgebung im Laufe der Zeit, wenn sich die Bedrohungslandschaft für Mobile-Banking-Apps weiterentwickelt.
Derzeit ist das wichtigste Mobile Banking Sicherheit Bedrohungen, die wir beobachten, sind:
- Überlagerungsangriffe: Malware auf dem mobilen Gerät zeigt ein Fenster über der echten Banking-App an, das der Banking-App sehr ähnlich ist. Die Malware zielt darauf ab, die Bankdaten des Benutzers (z. B. Benutzername, PIN) zu erfassen. Gängige Android-Malware-Familien wie Marcher und BankBot sind für solche Angriffe bekannt.
- Code-Injektion oder Einhaken: Malware versucht, die Funktionalität einer Mobile-Banking-App zu ändern. Beispielsweise könnte die App geändert werden, um den PIN-Code des Benutzers zu protokollieren oder den Begünstigten einer Finanztransaktion zu manipulieren. Hooking Frameworks wie Frida und Xposed stehen Betrügern hierfür frei zur Verfügung.
- Keylogging: Malware auf dem mobilen Gerät fängt Tastenanschläge oder Gesten ab, um vertrauliche Daten wie PINs zu stehlen.
- Abfangen von SMS-Nachrichten: SMS-Nachrichten werden mit Authentifizierungscodes unter Verwendung von Malware auf dem Telefon des Benutzers abgefangen. Dies ist heutzutage eine beliebte Funktion vieler mobiler Android-Malware-Familien.
So erstellen Sie eine sichere Ausführungsumgebung
Um eine sichere Ausführungsumgebung für Mobile-Banking-Apps zu erstellen, empfehlen wir, diese mithilfe der Application Shielding-Technologie zu schützen, die auch als bezeichnet wird Selbstschutz der Laufzeitanwendung oder RASP-Sicherheit. Diese Technologie schützt eine mobile App vor verschiedenen Arten von Laufzeitbedrohungen. Als solches wird eine virtuelle sichere Ausführungsumgebung für die App erstellt, die es ermöglicht, sie auch auf nicht vertrauenswürdigen Mobilgeräten auszuführen.
Anwendungsabschirmung schützt mobile Apps durch eine Kombination aus präventiven, detektivischen und reaktiven Ansätzen. Es verhindert Laufzeitbedrohungen, indem es beispielsweise Code verschleiert, um das Reverse Engineering zu erschweren. Es erkennt Angriffe zur Laufzeit, z. B. Versuche, die App zu manipulieren oder die App in einem Emulator auszuführen. Schließlich kann es auf Laufzeitangriffe auf unterschiedliche Weise reagieren, z. B. indem es die serverseitigen Risiko-Engines der Bank alarmiert oder sogar die App herunterfährt.
In diesem Whitepaper erfahren Sie mehr darüber, wie Sie Malware-Angriffe in Echtzeit identifizieren und blockieren können:
https://www.onespan.com/solutions/invisible-mobile-banking-channel-security
Dieser Artikel, verfasst von Frederik Mennes, Senior Manager Markt- und Sicherheitsstrategie im OneSpan Security Competence Center, erschien erstmals am 06/2018 in deutscher Sprache IT Finanzmagazin .
