PSD2: EBA-Stellungnahme erlaubt Fristverlängerung zur Einführung der starken Kundenauthentifizierung

Frederik Mennes, 10. Juli 2019
PSD2: European Banking Authority Allows More Time to Implement Strong Customer Authentication

Am 21. Juni 2019 hat die Europäische Bankenaufsichtsbehörde ( EBA ) veröffentlichte eine Meinung zur starken Kundenauthentifizierung (SCA) gemäß der überarbeiteten Richtlinie über Zahlungsdienste ( PSD2 ). Die Stellungnahme der EBA ermöglicht es den zuständigen Behörden (CAs), bestimmten Zahlungsdienstleistern (PSPs) ausnahmsweise zusätzliche Zeit nach dem 14. September 2019 zu gewähren, um die SCA-Anforderungen zu erfüllen. Außerdem wird klargestellt, ob gängige Authentifizierungsmethoden den SCA-Anforderungen von PSD2 entsprechen.

In diesem Artikel diskutiere ich die Klarstellungen der Stellungnahme der EBA und spreche auch einige Bereiche an, in denen zusätzliche Klarstellungen erforderlich sind.

Umfang der Erweiterung

Die Stellungnahme ermöglicht es den zuständigen Behörden (CAs), bestimmten Zahlungsdienstleistern (PSPs) ausnahmsweise zusätzliche Zeit nach dem 14. September 2019 zu gewähren, um die SCA-Anforderungen zu erfüllen. In der Stellungnahme heißt es insbesondere: Zertifizierungsstellen können beschließen, mit PSPs und relevanten Interessengruppen, einschließlich Verbrauchern und Händlern, zusammenzuarbeiten, um eine begrenzte zusätzliche Zeit zur Verfügung zu stellen, damit Emittenten zu Authentifizierungsansätzen migrieren können, die mit SCA kompatibel sind, wie in dieser Stellungnahme beschrieben, und Acquirer, zu denen ihre Händler migriert werden können Lösungen, die SCA unterstützen.

Daher bezieht sich die Stellungnahme in hohem Maße auf Emittenten, Erwerber und Händler, wenn die Möglichkeit erörtert wird, mehr Zeit für die Einhaltung zu erhalten. Diese Terminologie wird normalerweise im Zusammenhang mit der Kartenzahlung für den E-Commerce verwendet. Dies ist wahrscheinlich der Fall, weil die meisten Anfragen zur Verzögerung der September-Frist von E-Commerce-Unternehmen kamen.

Dies wirft die Frage auf, ob die zuständigen Behörden nur im Zusammenhang mit Kartenzahlungen für den elektronischen Handel zusätzliche Zeit gewähren und möglicherweise nicht im Zusammenhang mit anderen Anwendungen, die eine starke Authentifizierung erfordern, wie Online-Banking und Mobile-Banking. Wir haben die EBA gebeten, dies zu klären.

PSD2-konforme Betrugsüberwachung mit OneSpan Risk Analytics
WEISSES PAPIER

PSD2-konforme Betrugsüberwachung mit OneSpan Risk Analytics

Neue PSD2-Anforderungen erfordern, dass Finanzdienstleistungsunternehmen die Transaktionsüberwachung durchführen. In diesem Whitepaper erfahren Sie, welche spezifischen Anforderungen und wie OneSpan Risk Analytics Sie bei der Einhaltung der Richtlinien unterstützen kann.

Jetzt herunterladen

Zeitpunkt der Verlängerung

Wie oben erwähnt, erlaubt die Stellungnahme den zuständigen Behörden, „ begrenzte zusätzliche Zeit An PSPs, um die SCA-Anforderungen zu erfüllen. Die Stellungnahme sieht jedoch keine Frist vor. 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 am 14. September 2019 die Anforderungen erfüllt, und einem Erwerber durchgeführt wird, der eine Verlängerung von beispielsweise sechs Monaten erhalten hat, kann der Erwerber eine Zahlungsanforderung ohne SCA an den Aussteller senden. Der Emittent wird die Zahlung jedoch ablehnen, da SCA erforderlich ist. Infolgedessen könnten Zahlungen abgelehnt werden, obwohl sowohl der Emittent als auch der Erwerber korrekt handeln. Dies erhöht eindeutig die Notwendigkeit für Zertifizierungsstellen, Verlängerungen auf koordinierte Weise zu gewähren.

Anpassung der SCA- und Open Banking-Zeitpläne

Bisher gingen die Einführung von Open Banking APIs und SCA Hand in Hand und folgten demselben Zeitplan, wobei die Frist für beide der 14. September 2019 war. Die Stellungnahme der EBA lässt zusätzliche Zeit für die Implementierung der SCA-Anforderungen, jedoch keine zusätzliche Zeit für die Implementierung von Open Banking-APIs, der anderen Säule von PSD2. Infolgedessen könnten Banken Drittanbietern (TPPs) Open Banking APIs ohne SCA anbieten.

Dies hat eine Reihe von Konsequenzen:

  • Auswirkungen auf die Sicherheit: Wenn eine Bank Bankkonten nicht mit SCA schützt und die Authentifizierung über das eingebettete Modell unterstützt, erhalten TPPs schwache Anmeldeinformationen, die zum Schutz von Bankkonten verwendet werden. Wenn beispielsweise ein Bankkonto mit einem Benutzernamen und einem statischen Kennwort geschützt ist, kann das TPP diese Anmeldeinformationen erhalten. Infolgedessen könnte sich das TPP auf diesen Bankkonten anmelden und möglicherweise Zahlungen ausführen, ohne dass die Kontoinhaber davon Kenntnis haben.
  • Auswirkungen auf die Benutzererfahrung: Benutzer, die über ein TPP (oder genauer gesagt einen Kontoinformationsdienstleister oder AISP) auf ihre Bankkonten zugreifen, müssen möglicherweise SCA für Bank-A, jedoch nicht für Bank-B durchführen. Infolgedessen ist die Benutzererfahrung in der AISP-Anwendung für verschiedene Banken unterschiedlich, was verwirrend sein kann. Dies gilt auch für TPPs, die als Payment Initiation Service Provider (PISP) fungieren.
WEBCAST

Webinar: PSD2 Strong Customer Authentication Deadline Extension - Erläuterungen zur Stellungnahme der EBA

Informieren Sie sich vom PSD2-SCA-Experten Frederik Mennes über den Umfang und die Zeitpläne der SCA-Erweiterung und darüber, welche Authentifizierungslösungen den Anforderungen entsprechen.

Jetzt ansehen

 Konformität von Authentifizierungselementen

Die Regulatory Technical Standards (RTS) für eine starke Kundenauthentifizierung und eine gemeinsame und sichere Kommunikation von PSD2 definieren SCA als „ Authentifizierung basierend auf der Verwendung von zwei oder mehr Elementen, die als Wissen (etwas, das nur der Benutzer kennt), Besitz (etwas, das nur der Benutzer besitzt) und Inhärenz (etwas, das der Benutzer ist) unabhängig voneinander kategorisiert werden […] ”. Die Stellungnahme enthält Klarstellungen darüber, welche Authentifizierungselemente als stark angesehen werden können und in welche Kategorie sie fallen (dh Wissen, Besitz oder Inhärenz).

Nachfolgend einige bemerkenswerte Erläuterungen aus der Stellungnahme:

  • SMS als Besitzelement: In der Stellungnahme wird 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 oder 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 . Die EBA sollte diesbezüglich weitere Erläuterungen geben.
  • Mobile Apps als Besitzelement: Die Stellungnahme bekräftigt Artikel 7 des RTS, der impliziert, dass mobile Apps gültige Besitzelemente sind, wenn sie durch einen Gerätebindungsmechanismus geschützt sind, der die mobile App mit dem Gerät verbindet, auf dem sie ausgeführt wird. Eine mobile App, die nicht durch einen Gerätebindungsmechanismus geschützt ist, kann nicht als gültiges Besitzelement betrachtet werden.
  • OTP-Listen als Besitzelement: Finanzinstitute verwenden manchmal gedruckte Matrixkarten oder gedruckte OTP-Listen (manchmal als „TAN-Listen“ bezeichnet), um den Endbenutzer einer Online-Banking-Anwendung zu authentifizieren. In der Stellungnahme wird klargestellt, dass diese gedruckten Karten oder Listen kein gültiges Besitzelement darstellen, da sie leicht kopiert werden können (z. B. durch Fotografieren der Karte mit einem mobilen Gerät).

Es gibt eine Reihe von Themen, die in der Stellungnahme nicht behandelt werden und von einer weiteren Klärung profitieren würden. Ich habe Fragen zu diesen Themen über die eingereicht Das Q & A-Tool der EBA ::

  • Verwendung von teilweisen oder vollständigen IBANs bei der dynamischen Verknüpfung: Die Anforderung für die dynamische Verknüpfung besagt, dass der Authentifizierungscode über eine Kennung des Begünstigten berechnet werden muss. Angenommen, eine IBAN wird verwendet, um einen Begünstigten zu identifizieren. Ist es dann erforderlich, den Authentifizierungscode über die vollständige IBAN zu berechnen, oder reicht es aus, einen Teil davon zu verwenden? Ebenso reicht es aus Show nur ein Teil der IBAN an den Zahler? In der Praxis verwenden Banken häufig nur einen Teil der IBAN aus mehreren Gründen, da es unpraktisch ist, die vollständige IBAN einzugeben oder anzuzeigen.
  • Verwendung von Hash-Zahlungsinformationen: Im Zusammenhang mit der dynamischen Verknüpfung wird häufig die Frage aufgeworfen, ob der Authentifizierungscode über die Zahlungsinformationen (Betrag, Empfänger-ID) selbst berechnet werden muss oder ob die Berechnung des Authentifizierungscodes über einen Hash der Zahlungsinformationen ausreicht . Wenn der Authentifizierungscode über einen Hashwert berechnet wird und der Zahler nicht sieht, welche Zahlungsinformationen verwendet werden, verstehen die Zahler möglicherweise nicht, zu welcher Transaktion sie sich tatsächlich verpflichten. Social Engineering Angriffe gegen Authentifizierungssysteme nutzen dies oft aus.

Wir hoffen, dass die EBA zusätzliche Klarstellungen zu diesen Themen liefert.

Eine eingehendere Analyse der SCA-Anforderungen von PSD2 ist verfügbar auf meinem Blog .

Dieser Artikel, der ursprünglich am 2. Juli 2019 veröffentlicht wurde, erschien erstmals auf der persönlichen LinkedIn-Seite und im Wordpress-Blog von Frederik Mennes.

Frederik leitet das Sicherheitskompetenzzentrum von OneSpan, wo er für die Sicherheitsaspekte der Produkte und der Infrastruktur von OneSpan verantwortlich ist. Er verfügt über fundierte Kenntnisse in den Bereichen Authentifizierung, Identitätsmanagement, Regulierungs- und Sicherheitstechnologien