Starke Kundenauthentifizierung nach PSD2: Rundumabriss

In wenigen Tagen, am 14. September 2019, werden die lang erwarteten SCA-Anforderungen (Strong Customer Authentication) unter PSD2 endlich in Kraft treten. Diese Anforderungen wurden vor etwa 18 Monaten von der Europäischen Kommission in den Regulatory Technical Standards (RTS) für starke Kundenauthentifizierung und gemeinsame und sichere Kommunikation veröffentlicht und wirken sich auf die Art und Weise aus, wie Verbraucher in Europa auf ihre Internetbanking-Anwendungen zugreifen, für E-Commerce-Einkäufe bezahlen und Nutzung neuer Finanzdienstleistungen von Drittanbietern (TPPs) über Open Banking.
In diesem Artikel blicken wir auf SCA unter PSD2 zurück und bewerten, was gut gelaufen ist und was für einen weiteren erfolgreichen Einsatz von SCA in Europa erforderlich ist.
1) Das Gute
PSD2 erhöht das Sicherheitsniveau für die Authentifizierung bei Finanzdienstleistungen in ganz Europa und harmonisiert die Stärke der Authentifizierungsprozesse für Finanzanwendungen.Aufgrund von PSD2 haben Finanzinstitute schwache Authentifizierungsmethoden eingestellt. Beispiele sind Lösungen, die ausschließlich auf Kombinationen aus Benutzername und Passwort basieren, und Lösungen, die auf gedruckten Listen von Authentifizierungscodes wie TAN-Listen und Matrixkarten basieren. Wie aus der Stellungnahme der Europäischen Bankenaufsichtsbehörde (EBA) vom 21. Juni hervorgeht, erfüllen diese Lösungen nicht die SCA-Anforderungen.
PSD2 stellt sicher, dass fortschrittliche Authentifizierungskonzepte wie dynamische Verknüpfung, Gerätebindung für mobile Apps, Abschirmung mobiler Anwendungen und Analyse des Transaktionsrisikos zu Standard-Sicherheitstools für Finanzdienstleistungen werden. In dieser Hinsicht geht PSD2 viel weiter als die EBAs Endgültige Richtlinien zur Sicherheit von Internetzahlungen , die am 1. August 2015 in Kraft getreten ist und am 14. September durch PSD2 ersetzt wird.
PSD2 beschleunigt auch die Einführung adaptiver Authentifizierungsmethoden, mit denen die Art und Weise der Authentifizierung des Benutzers an das Risiko angepasst wird, was der Benutzer tun möchte. Als solches ermöglicht PSD2 ein benutzerspezifisches Gleichgewicht zwischen Komfort und Sicherheit. Dieser Ansatz wurde dank der Offenheit der EBA und der engen Zusammenarbeit mit den Akteuren der Branche bei der Ausarbeitung des RTS in das RTS aufgenommen.
2) Das Böse
PSD2 trägt die Verantwortung für den Schutz des Zugangs zu Bankkonten bei den Banken, auch bekannt als ASPSPs (Account Servicing Payment Service Providers). Da die Banken die Bankkonten besitzen, scheint dies auf den ersten Blick sinnvoll zu sein.
Bei näherer Betrachtung wird jedoch deutlich, dass dieser Ansatz im Kontext von Open Banking wie folgt erhebliche Komplexität verursacht:
- Zunächst müssen sich Benutzer von TPP-Anwendungen zweimal authentifizieren: einmal, um auf die TPP-Anwendung zuzugreifen, und ein zweites Mal, um ein bestimmtes Bankkonto über die TPP-Anwendung zu verwenden.
- Darüber hinaus hängen die Authentifizierungsmethode und der Ablauf für ein bestimmtes Bankkonto von der Bank ab. Beispielsweise könnte Bank A die Authentifizierung mithilfe eines Kartenlesegeräts und eines Umleitungsansatzes implementieren, während Bank B eine mobile App über den "entkoppelten" Ansatz verwenden könnte. Daher hängt die Benutzererfahrung innerhalb der TPP-Anwendung von der Bank ab.
Infolgedessen verspricht die allgemeine Authentifizierungserfahrung für den durchschnittlichen TPP-Benutzer kompliziert zu sein.
PSD2 selbst ist jedoch nicht dafür verantwortlich. Das Problem ist die Folge eines größeren Problems, das über PSD2 hinausgeht, nämlich das Fehlen eines europaweiten digitalen Identitätssystems, das auf verifizierten, vertrauenswürdigen Identitäten basiert. Inspiration für solche Systeme gibt es bereits in mehreren Ländern wie Schweden (Bank ID) und Indien (Aadhaar). Die Herausforderung besteht darin, ein solches System auf europäischer Ebene aufzubauen. Ein solches System ist der Schlüssel für die Zukunft von Open Banking.Citis jüngster Artikel liefert weitere Inspiration dafür.
3) Das Hässliche
Die SCA-Anforderungen von PSD2 sollen zukunftssicher und technologieunabhängig sein. Sie bieten Zahlungsdienstleistern (Payment Service Providern, PSPs) einen gewissen Spielraum, sodass PSPs entscheiden können, wie sie eine bestimmte Anforderung am besten erfüllen.Dies kann jedoch dazu führen, dass PSPs, die die Anforderungen erfüllen müssen, im Dunkeln bleiben. Einige Beispiele:
- Verwendung von SMS zur dynamischen Verknüpfung . Die EBA hat in ihrer Stellungnahme vom 21. Juni klargestellt, dass SMS als gültiges Besitzelement angesehen werden kann. Insbesondere ist die SIM-Karte in dem mobilen Gerät, das die SMS empfängt, ein gültiges Besitzelement. Dies bedeutet, dass per SMS übermittelte Einmalkennwörter (OTPs) verwendet werden können, um einen starken Authentifizierungsmechanismus zu erstellen, wenn sie mit einem zweiten Faktor (z. B. einem Kennwort oder einer PIN) kombiniert werden. In der Stellungnahme wird jedoch nicht klargestellt, ob SMS für die dynamische Verknüpfung verwendet werden kann. In der Tat sieht die Anforderung der dynamischen Verknüpfung in Artikel 5 des RTS vor, dass die Vertraulichkeit und Integrität von Zahlungsinformationen (z. B. Bankkontonummer, Geldbetrag) während des Authentifizierungsprozesses geschützt werden muss. Da der Inhalt einer SMS normalerweise nicht geschützt ist, scheint es SMS erfüllt nicht die Anforderungen für dynamische Verknüpfungen .
- Erstellen einer sicheren Ausführungsumgebung für mobile Apps . Das RTS besagt, dass PSPs 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. Angesichts des aktuellen Standes der Sicherheit mobiler Apps besteht der beste Ansatz zur Erfüllung dieser Anforderung wahrscheinlich in der Verwendung Anwendungsabschirmungstechnologie Schutz der App vor Bedrohungen wie Overlays, Code-Injection und Keylogging.
Schließlich hat sich der Zeitplan für die Durchsetzung der SCA-Anforderungen von PSD2 in den letzten Monaten verschoben. Ursprünglich sollten die SCA-Anforderungen für Internetbanking- und E-Commerce-Anwendungen am 14. September 2019 gelten. Am selben Tag würde die Anforderung, dass Banken eine Kommunikationsschnittstelle für Open Banking bereitstellen müssen, in Kraft treten. Seit die EBA am 21. Juni ihre Stellungnahme veröffentlicht hat, sind die Fristen jedoch fragmentierter geworden. Zum Zeitpunkt des Schreibens sind die Fristen wie folgt:
- Frist für die Implementierung von SCA für Internetbanking durch Banken: 14. September 2019, außer in Großbritannien, wo die Frist jetzt der 14. März 2020 ist
- Frist für die Implementierung von SCA für Kartenzahlungen für den E-Commerce: Länderspezifische Verzögerungen sind zulässig
- Frist für das Angebot von Open Banking-Schnittstellen durch Banken: 14. September 2019
Infolgedessen können unterschiedliche PSPs unterschiedliche Fristen haben, um die SCA-Anforderungen zu erfüllen, und dies kann sich auf Zahlungen auswirken, an denen mehrere PSPs beteiligt sind. Wenn beispielsweise eine Kartenzahlung zwischen einem Kartenaussteller, der die Anforderungen ab dem 14. September 2019 erfüllt, und einem Erwerber durchgeführt wird, der eine Verlängerung von beispielsweise 6 Monaten erhalten hat, kann der Erwerber eine Zahlungsanforderung ohne SCA an den Aussteller senden, jedoch an die Der Emittent lehnt die Zahlung ab, da SCA erforderlich ist. Infolgedessen könnten Zahlungen abgelehnt werden, obwohl sowohl der Emittent als auch der Erwerber korrekt handeln. Dies macht deutlich, dass die zuständigen Behörden (CAs) Verlängerungen auf koordinierte Weise gewähren müssen. Die EBA sollte hier die Rolle des Koordinators zwischen den verschiedenen Zertifizierungsstellen spielen.
In Sergio Leones epischem Film von 1966 nimmt das Gute das Gold, das Böse stirbt und das Hässliche wird durch die Gnade des Guten gerettet. Hoffen wir, dass das Skript des Films auch für PSD2 gilt.
Eine eingehendere Analyse von PSD2 und seinen starken Anforderungen an die Kundenauthentifizierung ist hier verfügbar .