Biometrie und Payer Awareness bei der dynamischen Verknüpfung

Der Ansatz von Corbado kombiniert Phishing-resistente Passkeys (SCA) mit einer von der Bank kontrollierten Anzeige und einer serverseitigen dynamischen Verknüpfung, um Art. 5 der PSD2 RTS („What-you-see-is-what-you-sign“) zu erfüllen.

• Kernimplementierung (heute): Wir zeigen den Transaktionsbetrag und den Zahlungsempfänger in einer von der Bison-Bank kontrollierten Benutzeroberfläche unmittelbar vor und während der Passkey-Authentifizierung an. Unser Backend erzeugt eine einmalige Challenge, die an einen kanonisierten Transaktions-Snapshot (Betrag, Zahlungsempfänger, Transaktions-ID) gebunden ist. Die Antwort wird nur akzeptiert, wenn sie mit diesem Snapshot übereinstimmt; jede Änderung macht sie ungültig.

• Regulatorische Position: Die dynamische Verknüpfung bleibt auch mit Passkeys für Remote-Zahlungen erforderlich (PSD2 Art. 97(2); RTS Art. 5). Die RTS verlangen nicht, dass der „Authentifizierungscode“ der dynamischen Verknüpfung auf dem Gerät berechnet wird; eine serverseitige Erzeugung/Validierung ist akzeptabel, wenn die Integrität der Anzeige, die Spezifität und die Invalidierung bei Änderungen durchgesetzt werden (siehe auch EBA Q&A 2020_5366 zur Frage, wo der Code berechnet werden kann).

• Sicherheit & Überprüfbarkeit: Die Bindung einer hardware-verankerten, Phishing-resistenten Passkey-Signatur an spezifische Transaktionsdaten verhindert Manipulationen und Relay-Angriffe und liefert einen starken, unanfechtbaren Nachweis der Zustimmung des Zahlers. Wo unterstützt, können wir optional Secure Payment Confirmation (SPC) einsetzen, um einen kryptografischen Beweis für die angezeigten Details hinzuzufügen, ohne das Backend-Modell zu ändern.

• SCA: Zwei unabhängige Elemente aus unterschiedlichen Kategorien (Wissen/Besitz/Inhärenz), die mit geeigneten Maßnahmen gegen Offenlegung/Replikation geschützt sind (RTS Art. 6–8). Unabhängigkeit ist erforderlich (Art. 9), einschließlich der Trennung bei der Ausführung auf Mehrzweckgeräten (z. B. Schutzmechanismen auf Betriebssystemebene, sichere Hardware).
• Dynamische Verknüpfung (RTS Art. 5):
  • (i) Der Zahler wird während der Authentifizierung über Betrag und Zahlungsempfänger informiert.
  • (ii) Der Authentifizierungscode ist spezifisch für diesen Betrag/Zahlungsempfänger.
  • (iii) Jede Änderung macht den Code ungültig.
  • (iv) Vertraulichkeit/Integrität von Betrag, Zahlungsempfänger und Code sind durchgängig geschützt. Dies setzt die regulatorische Absicht „What-you-see-is-what-you-sign“ um.
• Implikation: Eine starke Nutzerauthentifizierung allein reicht für Zahlungen nicht aus. Die Genehmigung muss an spezifische Transaktionsdaten gebunden sein, mit einem überprüfbaren Nachweis der Bindung und der Anzeige für den Zahler (RTS Art. 5(1)(a–d)).

Klarstellung — Phishing vs. Autorisierung: Passkeys sind ursprungsgebunden, sodass gefälschte Domains keine gültigen Signaturen hervorrufen können. Dennoch verlangt die PSD2 für Remote-Zahlungen weiterhin eine dynamische Verknüpfung, um die Autorisierung an den exakten Betrag und Zahlungsempfänger zu binden, jede Änderung ungültig zu machen und die Integrität dessen zu schützen, was dem Zahler angezeigt wird (RTS Art. 5(1)(a–d)). Die dynamische Verknüpfung befasst sich mit der Integrität der Autorisierung (einschließlich MITM/MITB/TPP-Substitution), nicht nur mit Phishing.

Die EBA-Stellungnahme 2019 (EBA‑Op‑2019‑06) bekräftigt, dass die dynamische Verknüpfung die Authentifizierung an Betrag und Zahlungsempfänger bindet, die Unabhängigkeit der Faktoren erfordert und gerätegebundene kryptografische Schlüssel als Besitzfaktor akzeptiert, wenn eine eindeutige Gerätebindung besteht. Sie betont auch die Integrität dessen, was dem Zahler während der Authentifizierung angezeigt wird. EBA Opinion 2019

Vor der PSD2 verließen sich viele Banken auf SMS-OTPs oder gedruckte TAN-Listen, die oft weder den Betrag noch den Zahlungsempfänger neben dem Genehmigungsschritt anzeigten. Diese Lücke machte es einfacher, Kunden nach dem Diebstahl von Zugangsdaten zur Autorisierung unbeabsichtigter Überweisungen zu verleiten. Die dynamische Verknüpfung wurde eingeführt, um diese Lücke zu schließen, indem sichergestellt wird, dass der Zahler zum Zeitpunkt der Authentifizierung über den genauen Betrag und den Zahlungsempfänger informiert wird und der Authentifizierungscode spezifisch für diese Details ist, sodass jede Änderung ihn ungültig macht (RTS Art. 5(1)(a–d)). Wenn SMS Teil des Prozesses sind, müssen Issuer auch die Vertraulichkeit, Authentizität und Integrität von Betrag/Zahlungsempfänger und des Codes in allen Phasen der Authentifizierung gewährleisten (Q&A 2018_4414; RTS Art. 5(2)). Heutige In-App-Genehmigungen (zum Beispiel: „Möchten Sie 100 USD an Max Mustermann via Face ID autorisieren?“) setzen dieses „What you see is what you sign“-Prinzip kundenfreundlich um.

Heute dominieren auf Mobilgeräten zwei Muster. Erstens kann eine Push-Benachrichtigung den Kunden per Deep-Link in die App leiten, um die Transaktionsdetails zu überprüfen und zu genehmigen. Aufsichtsbehörden haben klargestellt, dass Push als Nachweis für das Besitzmerkmal dienen kann, wenn Kontrollen gemäß Artikel 7 zur Eindämmung unbefugter Nutzung und zur Verhinderung von Replikation vorhanden sind und der gesamte Prozess den RTS entspricht; dennoch bleiben Risiken durch Social Engineering bestehen und sollten in der UX berücksichtigt werden (Q&A 2019_4984; RTS Art. 7).

Zweitens führen Genehmigungen mit der nativen Biometrie des Geräts (mit PIN-Fallback) eine Nutzerverifizierung lokal durch, um eine Private-Key-Operation freizuschalten. Der private Schlüssel befindet sich in einer sicheren Hardware-Umgebung (Secure Enclave/TEE/TPM) und signiert eine Challenge. Dies lässt sich sauber auf die SCA abbilden: Inhärenz (Biometrie) plus Besitz, nachgewiesen durch Gerätebindung und einen gerätegebundenen kryptografischen Schlüssel (EBA-Op-2019-06, Abs. 25, 35–37). Bei Remote-Zahlungen muss der Code dynamisch mit dem Betrag und dem Zahlungsempfänger verknüpft sein, und diese Details müssen dem Zahler vor der Nutzerverifizierung angezeigt werden (RTS Art. 5). Wenn sich beide Faktoren auf einem Gerät befinden, müssen separate sichere Ausführungsumgebungen und Integritätsprüfungen implementiert werden, damit eine Kompromittierung des einen nicht den anderen gefährdet (RTS Art. 9(2)–(3)).

Technisch gesehen authentifizieren sich lokale biometrische Daten nicht direkt bei der Bank. Stattdessen führt die Biometrie (oder der PIN-Fallback) eine Nutzerverifizierung auf dem Gerät durch und steuert den Zugriff auf einen nicht exportierbaren privaten Schlüssel, der in einem hardwaregestützten Sicherheitsmodul gespeichert ist. Wenn der Zahler zustimmt, verwendet das Gerät diesen privaten Schlüssel, um eine digitale Signatur über eine von der Bank bereitgestellte Challenge zu erzeugen. Wenn die Bank diese Challenge aus einem kanonischen Snapshot der Transaktion (Betrag, Zahlungsempfänger, Kennungen) ableitet oder damit verknüpft, fungiert die resultierende Signatur als Authentifizierungscode, der spezifisch für diese Details ist. Jede Änderung macht den Code ungültig, weil der gespeicherte Snapshot nicht mehr übereinstimmt oder, in erweiterten Designs, weil sich die Ableitung der Challenge ändert. Der Teil des Payer Awareness bleibt eine UX-Anforderung: Zeigen Sie den Betrag und den Zahlungsempfänger in einer von der Bank kontrollierten Ansicht unmittelbar vor der Nutzerverifizierung an. Zusammen erfüllt dies die Anforderungen von RTS Art. 5 an das Bewusstsein, die Spezifität/Einzigartigkeit und die Ungültigkeit bei Änderungen, während Kontrollen nach Artikel 7 und die Gerätebindung das Besitzmerkmal nachweisen.

• Besitz (gerätegebundene & synchronisierte Schlüssel): Private Schlüssel von Passkeys werden in sicherer Hardware (TEE/Secure Enclave/TPM) gespeichert. Gerätegebundene Passkeys sind nicht exportierbar, was den EBA-Erwartungen für eine eindeutige Gerätebindung entspricht (EBA-Op-2019-06, Abs. 25, 35–37). Synchronisierte Passkeys können den Besitz bei jeder Authentifizierung ebenfalls nachweisen, sofern die Gerätebindung und die Anti-Replikations-Kontrollen wirksam sind; die Aufsichtsbehörden haben die Notwendigkeit einer verlässlichen Verbindung zwischen dem Element und dem Gerät betont (EBA-Op-2019-06; RTS Art. 7).
• Inhärenz/Wissen (Nutzerverifizierung): Die Nutzerverifizierung per Biometrie (Inhärenz) oder Geräte-PIN (Wissen) aktiviert den Schlüssel lokal. In Kombination mit dem Besitz ergibt dies eine echte 2FA mit Faktorunabhängigkeit. Eine Kompromittierung des einen Faktors gefährdet den anderen nicht.

Bei der dynamischen Verknüpfung geht es darum, die Authentifizierung an die Transaktion zu binden. Die Frage für eine Bank lautet: Wenn wir einem Nutzer erlauben, eine Zahlung per Passkey (statt z. B. mit einem OTP oder einem Signaturgerät) zu genehmigen, können wir dann garantieren, dass diese Genehmigung spezifisch für den beabsichtigten Betrag und Zahlungsempfänger ist und nicht wiederverwendet oder manipuliert werden kann?

Es gibt zwei Möglichkeiten, die dynamische Verknüpfung mit Passkeys umzusetzen:

• Serverseitige Verknüpfung (Standard): Eine einmalige WebAuthn-Challenge wird generiert, die das Backend mit dem exakten Betrag und Zahlungsempfänger verknüpft. Der Nutzer sieht „X € an Y“ in einer von der Bank kontrollierten Ansicht und genehmigt mit einem Passkey. Die Antwort wird nur für diese Transaktion akzeptiert. Jede Änderung macht sie ungültig.
• Kryptografische Einbindung (erweitert): Ein Hash von Betrag/Zahlungsempfänger wird in die Challenge eingebettet, sodass die Signatur sich auf die Transaktionsdaten festlegt. Dies wird von den RTS nicht gefordert, bietet aber zusätzliche Sicherheit, dass selbst Manipulationen im Backend bei der Verifizierung fehlschlagen würden.

Expliziter Compliance-Hinweis: Die RTS verlangen nicht, dass der „Authentifizierungscode“ der dynamischen Verknüpfung auf dem Gerät des Zahlers berechnet wird. Ein PSP darf ihn auf dem Server erzeugen und validieren, solange Betrag/Zahlungsempfänger geschützt sind und jede Änderung den Code ungültig macht (siehe EBA Q&A 2020_5366 zum Ort/Zeitpunkt der Code-Berechnung). Das ist unser Ansatz der serverseitigen dynamischen Verknüpfung (Standard).

Beide Ansätze ergeben einen einzigartigen, nicht wiederverwendbaren „Authentifizierungscode“, der spezifisch für die Transaktion ist. Der Hauptvorbehalt ist das Bewusstsein des Zahlers: WebAuthn selbst beweist nicht, was angezeigt wurde. Die Integrität der Anzeige muss durch eine von der Bank kontrollierte Benutzeroberfläche sichergestellt werden.

RTS Artikel 5 verlangt, dass der Zahler den Betrag und den Zahlungsempfänger während der Authentifizierung sieht. WebAuthn bestätigt nicht, was angezeigt wurde. Theoretisch könnte ein Nutzer bei einer Kompromittierung der App oder des Betriebssystems getäuscht werden, während der Authenticator dennoch signiert. Wir analysieren im Folgenden detailliert, wie sich dieses Risiko in der Praxis auswirkt und warum es weniger ein reales Sicherheitsrisiko als vielmehr eine Frage der Auslegung von Vorschriften ist.

Kontrollen zur Integrität der Anzeige, die wir durchsetzen:

• Eine von der Bank kontrollierte Ansicht rendert Betrag + Zahlungsempfänger: Wir blockieren den Passkey-Aufruf, wenn die Ansicht verdeckt ist oder den Fokus verliert.
• Overlay-/Manipulationserkennung in App/Web: keine Passkey-Aufforderungen aus versteckten iframes.
• Prüfung der Geräteintegrität/Attestierung: Ablehnung oder Eskalation bei Signalen für gerootete/jailbroken/kompromittierte Geräte.
• Atomare Genehmigung gegen einen auf dem Server gehaltenen Snapshot von Betrag/Zahlungsempfänger: Bei jeder Parameteränderung ist eine neue Challenge erforderlich.

Über kryptografische Einbindung: WebAuthn-Erweiterungen zur „Transaktionsanzeige“ (SPC) werden heute nicht breit unterstützt. Unsere portable Basislösung ist die serverseitige Bindung, verstärkt durch die Ableitung der Challenge aus dem Transaktions-Snapshot (z. B. H(Betrag || Zahlungsempfänger || Transaktions-ID || Nonce)), sodass die Signatur sich auf diese Werte festlegt.

Beide Muster verwenden Public-Key-Kryptografie mit nicht exportierbaren Geräteschlüsseln und stützen sich auf eine lokale Nutzerverifizierung, um die Signaturoperation freizuschalten. In beiden Fällen stellt die Bank das Bewusstsein des Zahlers sicher, indem sie Betrag und Zahlungsempfänger in einer von der Bank kontrollierten Ansicht unmittelbar vor der Nutzerverifizierung anzeigt, und stellt die Spezifität sicher, indem sie den Authentifizierungscode an diese Details bindet – und ihn bei jeder Änderung ungültig macht (RTS Art. 5(1)(a–d)). Die RTS sind technologieneutral und verlangen nicht, dass Betrag/Zahlungsempfänger innerhalb eines biometrischen Modals des Betriebssystems gerendert werden; sie verlangen die Anzeige für den Zahler und die Bindung des Codes (RTS Art. 5). Wenn beide SCA-Elemente auf einem Gerät ausgeführt werden, gelten die Integritäts- und Trennungsanforderungen von Artikel 9 gleichermaßen (RTS Art. 9(2)–(3)). Schließlich ist der Ort der Berechnung für die dynamische Verknüpfung flexibel: Sie kann serverseitig erfolgen, wenn die Integrität gewahrt bleibt und jede Änderung den Code ungültig macht (Q&A 2020_5366). Dies sind dieselben Bedingungen, unter denen die Aufsichtsbehörden bereits lokale Biometrie mit PKI akzeptieren – daher sollten Passkeys, die mit denselben Kontrollen für Payer Awareness und Bindung implementiert werden, auf äquivalenter Basis akzeptiert werden.

Erfüllen also einfache Passkeys gemäß dem WebAuthn-Standard die Absicht der dynamischen Verknüpfung? Teilweise:

• MITM/Netzwerkangriffe: Ja. Ursprungsbindung und signaturspezifische Challenges verhindern Manipulation und Replay-Angriffe.
• Transaktionsintegrität: Ja. Die serverseitige Verknüpfung oder das Hashing der Challenge stellt sicher, dass nur der ursprüngliche Betrag/Zahlungsempfänger verifiziert wird.
• Zustimmung des Zahlers: Schwieriger. Passkeys fehlt eine Anzeige auf Authenticator-Ebene. UI-Täuschung auf kompromittierten Geräten könnte möglich sein. Es muss etwas Zusätzliches implementiert werden, um die Zustimmung des Zahlers zu gewährleisten.

Warum die dynamische Verknüpfung auch mit Passkeys notwendig ist

• Rechtlich: PSD2 Art. 97(2) und RTS Art. 5 schreiben die dynamische Verknüpfung für alle Remote-Zahlungsauslösungen vor. Es gibt keine Ausnahme für Phishing-resistente Methoden.
• Sicherheit: Passkeys beseitigen Cross-Origin-Phishing, aber sie belegen an sich nicht, was dem Zahler angezeigt wurde. Dynamische Verknüpfung und Kontrollen zur Integrität der Anzeige stellen sicher, dass der spezifische Betrag/Zahlungsempfänger, den der Nutzer gesehen hat, von der Bank ausgeführt wird und dass jede Änderung die Genehmigung ungültig macht.

Zusammenfassend lässt sich sagen, dass Passkeys die dynamische Verknüpfung erfüllen können, wenn sie streng an Transaktionsdaten gebunden und mit vertrauenswürdigen Anzeigemechanismen gekoppelt sind. Die verbleibende Herausforderung besteht darin, zu beweisen, was der Nutzer tatsächlich gesehen hat.

Corbado bietet eine mit der dynamischen Verknüpfung konforme Lösung, die die oben genannten Überlegungen zur Zustimmung des Zahlers explizit berücksichtigt.

// TODO PROVIDE MOCKUPS FROM KARUNA AND DESCRIBE THEM

Prozessablauf:

• Eine von der Bank kontrollierte Anzeige zeigt dem Zahler den exakten Betrag und den Zahlungsempfänger. Eine Passkey-Aufforderung wird nur angezeigt, wenn diese Ansicht sichtbar ist.
• Authentifizierung: Der Client ruft WebAuthn mit einer einmaligen, gebundenen Challenge für die kanonisierte Transaktion auf. Der Authenticator führt eine Nutzerverifizierung (Biometrie oder Geräte-PIN) durch und signiert die Challenge und den Ursprung.
• Server-Verifizierung: Das Backend verifiziert den RP-ID-Hash und den Ursprung, gleicht die Challenge mit der gespeicherten Transaktion ab, prüft UV/Flags, erzwingt die einmalige Verwendung und den Ablauf und vergleicht den gespeicherten Snapshot von Betrag/Zahlungsempfänger.
• Genehmigung und Audit: Erst dann wird die Transaktion atomar genehmigt. Jede Abweichung/Änderung wird abgelehnt und erfordert eine neue Authentifizierung. Ein unveränderlicher Audit-Eintrag wird gespeichert (Credential-ID, authenticatorData, clientDataJSON, Signatur, Challenge und kanonisierter Betrag/Zahlungsempfänger), optional mit Hash-Ketten als Manipulationsnachweis.
• Prüfung der Geräteintegrität: Bewertung der Signale zur Geräteintegrität und Attestierung: Ablehnung oder Eskalation, wenn das Gerät gerootet/jailbroken/kompromittiert ist.
• Kanonisierung des Zahlungsempfängers: Anzeige eines benutzerfreundlichen Namens (z. B. „ACME GmbH“), aber Bindung und Verifizierung gegen einen kanonischen Zahlungsempfänger-Identifikator (z. B. IBAN/BIC oder ein anderes eindeutiges Schema).

Technische Details:

• Backend: Erstellen eines Transaktionsobjekts mit kanonisierten Daten (z. B. normalisierte Währung/Dezimalstellen; kanonisierte IBAN/Begünstigter). Generieren einer kurzlebigen Challenge, die sich auf diese Werte festlegt (z. B. H(Betrag||Zahlungsempfänger||Transaktions-ID||Nonce)); als ausstehend speichern; dem Client nur undurchsichtige IDs zur Verfügung stellen.
• Client/Authenticator: Rendern der Zahlerdetails in einer von der Bank kontrollierten Ansicht; WebAuthn (RP-ID = Bison-Domäne) nur aufrufen, wenn sichtbar; Nutzerverifizierung anfordern; Authenticator signiert Challenge + Ursprung gemäß WebAuthn.
• Verifizierung/Finalisierung: Validierung von Signatur, RP-ID-Hash, Ursprung/Typ, UV-Flags; Anti-Replay/Ablauf; Vergleich des unveränderlichen Snapshots von Betrag/Zahlungsempfänger; atomare Genehmigung; Speicherung des Audit-Eintrags.
• Ableitung der Challenge aus dem Snapshot:: challenge = H(Betrag ‖ kanonischerZahlungsempfänger ‖ Transaktions-ID ‖ Nonce)

UX-Richtlinien:

• Klare Hervorhebung von Betrag/Zahlungsempfänger; zugängliche Bestätigungs-/Abbruch-Steuerelemente; kurze Timeouts; reibungslose Wiederholungsversuche immer mit einer neuen Challenge; sofortige Bestätigungen (z. B. „Sie haben X € an Y genehmigt“). Blockieren Sie die Passkey-Aufforderung, wenn die Anzeige verdeckt ist, und warnen Sie, wenn sich Parameter vor dem Signieren ändern.
• Erkennen von Overlays/verdeckten Inhalten: Zeigen Sie niemals eine Passkey-Aufforderung an, wenn die Transaktionsansicht nicht sichtbar ist. Lehnen Sie ab, wenn sich Parameter während des Vorgangs ändern, und starten Sie mit einer neuen Challenge neu.

Compliance-Hinweis: Dieses End-to-End-Design erfüllt RTS Art. 5: Bewusstsein des Zahlers (von der Bank kontrollierte Anzeige), Spezifität und Einzigartigkeit (einmaliger Code, gebunden an Betrag/Zahlungsempfänger), Ungültigkeit bei Änderung (strikte Serverprüfungen) und Vertraulichkeit/Integrität von Betrag/Zahlungsempfänger und dem Code in allen Phasen (RTS Art. 5(1)(a–d), 5(2); siehe auch Q&A 2018_4414 zur SMS-Integrität). Die Faktorunabhängigkeit (Art. 7–9) wird durch gerätegebundenen Besitz und lokale Nutzerverifizierung auf Mehrzweckgeräten mit angemessenen Schutzmaßnahmen gewahrt (RTS Art. 9(2)–(3)).

Hinweis:

• Für Web-Flows wird Corbado optional[Secure Payment Confirmation] (https://www.w3.org/TR/payment-request-secure-payment-confirmation/) einsetzen, wenn/sobald Apple breite Unterstützung bietet, was eine vertrauenswürdige, vom Browser vermittelte Anzeige hinzufügt, die Betrag und Zahlungsempfänger kryptografisch bestätigt.

Problem: Phishing-Angriffe Lösung: Passkeys sind von Natur aus Phishing-resistent: Sie sind an den legitimen Ursprung gebunden und beinhalten keine geteilten Geheimnisse, sodass Anmeldeinformationen im Gegensatz zu OTPs nicht auf einer gefälschten Website abgegriffen werden können. Ein Angreifer, der den Datenverkehr zu einer ähnlich aussehenden Domain weiterleitet, kann keine gültige Signatur für den Ursprung der Bank erhalten. Die dynamische Verknüpfung trägt in diesem Vektor weniger bei, bleibt aber obligatorisch, um sicherzustellen, dass jede Genehmigung einzigartig für den beabsichtigten Betrag und Zahlungsempfänger ist. Ergänzende Maßnahmen (Aufklärung über Phishing, klare Trennung von Login- und Zahlungsgenehmigungen, Anomalie-/Risikobewertung für ungewöhnliche Zahlungsvorgänge) reduzieren das Risiko weiter.

Problem: Social Engineering / Authorized Push Payment (APP) Betrug Lösung: Kein Authenticator kann einen Nutzer vollständig daran hindern, eine Zahlung unter falschen Vorwänden zu autorisieren (z. B. „sicheres Konto“-Betrug). Die dynamische Verknüpfung stellt sicher, dass der Nutzer den Zahlungsempfänger und den Betrag explizit sieht und liefert einen starken Nachweis der Zustimmung, kann aber einen überzeugten Zahler nicht überstimmen. Kompensierende Maßnahmen umfassen kontextbezogene Warnungen (neuer Zahlungsempfänger, erste große Überweisung), Abkühlphasen oder verzögerte Ausführung für Hochrisiko-Zahlungsempfänger, eine stärkere Überprüfung des Zahlungsempfängers und Eskalationsprüfungen (zusätzliche Bestätigung) bei Risikosignalen. Benachrichtigungen nach der Zahlung und schnelle Streitbeilegungskanäle helfen, Schäden zu erkennen und einzudämmen. Wir fügen echtzeitbasierte kontextbezogene Warnungen (z. B. neuer Zahlungsempfänger, erste große Überweisung), Abkühlphasen für Hochrisiko-Zahlungsempfänger, eine stärkere Überprüfung des Zahlungsempfängers und Benachrichtigungen nach der Zahlung („Sie haben X € an Y genehmigt“) hinzu, um die Erkennung und Reaktion zu beschleunigen.

Problem: Malware oder Kompromittierung des Geräts Lösung: Private Schlüssel sind nicht exportierbar und erfordern für jede Signatur eine lokale Nutzerverifizierung, sodass Malware Anmeldeinformationen nicht einfach exfiltrieren kann. Das realistische Risiko ist eine UI-Täuschung auf einem vollständig kompromittierten Betriebssystem. Gegenmaßnahmen umfassen eine sichere/verifizierte Benutzeroberfläche (z. B. geschützte Bestätigungen), Überprüfungen der Geräteintegrität/Attestierung und das Blockieren von Hochrisikogeräten sowie vertrauenswürdige Bestätigungen wie SPC oder eine Bestätigungserweiterung, wenn verfügbar. Wenn Anzeichen für eine Kompromittierung auftreten (Overlay-Erkennung, Root/Jailbreak), sollte eine Out-of-Band-Neuverifizierung verwendet oder die Ausführung verweigert werden. Keine Verbrauchermethode ist auf einem vollständig übernommenen Gerät perfekt, aber diese Kontrollen verringern das Angriffsfenster erheblich.

Problem: Man-in-the-Browser / Session Hijacking Lösung: Bösartige Erweiterungen oder eingeschleuste Skripte können Aktionen auf dem legitimen Ursprung auslösen. Ursprungsgebundene Passkeys stoppen Cross-Site-Phishing. Die dynamische Verknüpfung stellt sicher, dass im Hintergrund vorgenommene Änderungen an Betrag/Zahlungsempfänger fehlschlagen. Wir härten den Kanal durch CSP/Anti-Tamper-Kontrollen und indem wir für jede Bestätigung eine neue, einmalige Challenge verlangen.

Problem: Insider-Bedrohung oder serverseitige Manipulation Lösung: Die Authentifizierungsantwort ist eindeutig mit dem ursprünglichen Betrag/Zahlungsempfänger verknüpft, sodass jede serverseitige Substitution bei der Validierung fehlschlägt. Führen Sie manipulationssichere, unveränderliche Verknüpfungsdatensätze (Challenge, Credential, Signatur und kanonisierter Betrag/Zahlungsempfänger) für Audit/Nichtabstreitbarkeit. Wenden Sie das Vier-Augen-Prinzip und die Funktionstrennung auf kritischen Pfaden der Zahlungsverarbeitung an, um das Insider-Risiko zu reduzieren.

Problem: Gestohlene Geräte / Diebstahl von Anmeldeinformationen Lösung: Der reine Besitz des Geräts reicht nicht aus: Für jede Signatur ist eine Nutzerverifizierung (Biometrie/PIN) mit Ratenbegrenzungen und Sperren auf Betriebssystemebene erforderlich. Jede Zahlung erfordert eine neue, transaktionsspezifische Challenge; generische Sitzungstoken können keine beliebigen Zahlungen autorisieren. Ergänzungen wie die Remote-Sperrung von Geräten, eine Eskalation bei der Nutzung eines neuen Geräts, Geovelocity-Prüfungen und Benachrichtigungen („Sie haben X € an Y autorisiert“) schränken den Missbrauch weiter ein.

Insgesamt: Passkeys reduzieren Phishing- und Replay-Risiken erheblich; die dynamische Verknüpfung bleibt unerlässlich, um die Transaktionsintegrität zu gewährleisten, Genehmigungen an Betrag/Zahlungsempfänger zu binden und einen starken Nachweis für eine informierte Zustimmung in den verbleibenden Bedrohungsszenarien zu liefern.

Frage 1: Wie können wir beweisen, dass der Nutzer den Betrag und den Zahlungsempfänger bei der Verwendung eines Passkeys tatsächlich gesehen und zugestimmt hat? Lösung: Wir erzwingen die Anzeige für den Zahler in einer von der Bank kontrollierten Ansicht und knüpfen die Genehmigung an einen serverseitigen Snapshot von Betrag/Zahlungsempfänger. Die Passkey-Assertion (authenticatorData, clientDataJSON, Signatur) wird nur für die aus diesem Snapshot abgeleitete Challenge akzeptiert; jede Änderung erfordert eine neue Challenge. Unser manipulationssicherer Audit verknüpft die Assertion mit „X € an Zahlungsempfänger-ID Y“ und zeichnet auf, dass unser System bei abweichenden Details nicht fortgefahren wäre. Wo unterstützt, fügt SPC einen kryptografischen Nachweis hinzu, dass der Nutzer die angezeigten Details bestätigt hat.

Frage 1: Wie können wir beweisen, dass der Nutzer den Betrag und den Zahlungsempfänger bei der Verwendung eines Passkeys tatsächlich gesehen und zugestimmt hat? Lösung: Dies ist im Wesentlichen die Frage der Nichtabstreitbarkeit. Unter PSD2 sollte die dynamische Verknüpfung sicherstellen, dass der Nutzer weiß, was er genehmigt. Mit einem Passkey behalten wir als Beweis die kryptografische Signatur (Authentifizierungscode) und die zugehörigen Daten (mit welchem Betrag/Zahlungsempfänger sie auf unserem Server verknüpft war) auf. Gemäß unserer Richtlinie zeigen wir dem Nutzer die Transaktionsdetails in der App oder auf der Webseite an, bevor er sich authentifiziert. Wir protokollieren diesen Bildschirm/diese Ansicht und die anschließende erfolgreiche Passkey-Authentifizierung für diese spezifische Transaktion. Im Streitfall können wir nachweisen, dass das Gerät des Nutzers eine gültige Signatur für eine Challenge erzeugt hat, die mit (z. B.) „100 € an ACME Corp.“ verknüpft war, und dass unser System bei abweichenden Details nicht fortgefahren wäre. Unsere Compliance beruht auf sicherer Protokollierung: Wir stellen sicher, dass unsere Systeme manipulationssicher sind, indem sie die Passkey-Antwort mit den Transaktionsdaten verknüpfen.

Frage 2: Was ist, wenn das Gerät oder das Betriebssystem kompromittiert ist? Kann Malware die Transaktion oder den Passkey-Prozess manipulieren? Lösung: Die Kompromittierung eines Geräts ist in jedem digitalen Banking-Szenario eine kritische Bedrohung. Wenn das Betriebssystem bösartig ist, könnte es versuchen, den Nutzer in die Irre zu führen oder Prozesse zu kapern. Doch selbst in diesem schlimmsten Fall behalten Passkeys einige wichtige Schutzmechanismen bei. Der private Schlüssel kann nicht von Malware extrahiert werden. Malware kann sich auch nicht als der Nutzer bei der Bank ausgeben, da sie ohne die Biometrie/PIN des Nutzers keine Passkey-Signatur erzeugen kann. Das Äußerste, was sie tun könnte, ist, den Nutzer dazu zu bringen, etwas unter falschen Vorwänden zu authentifizieren. Hier hilft die dynamische Verknüpfung durch Integritätsprüfungen: Die Malware kann die Transaktionsdetails nicht stillschweigend im Nachhinein ändern – wenn sie es tut, wird die Signatur nicht verifiziert. Der schwächste Punkt ist die Anzeige/UI: Ein ausgeklügelter Trojaner könnte verändern, was der Nutzer sieht (z. B. „ACME Corp“ anzeigen, während die zugrunde liegende Transaktion tatsächlich an einen anderen Zahlungsempfänger geht). Das ist nicht trivial, besonders wenn die Bank-App sichere UI-Frameworks verwendet, aber es ist denkbar. Wenn wir jedoch Anzeichen für eine Gerätekompromittierung erkennen (ungewöhnliches Verhalten, bekannte Malware-Signaturen usw.), würden wir auf eine Out-of-Band-Verifizierung zurückgreifen oder die Transaktion verweigern. Zusammenfassend: Keine Lösung ist 100%ig sicher, wenn das Gerät des Nutzers vollständig von einem Angreifer kontrolliert wird. Passkeys und dynamische Verknüpfung reduzieren die Angriffsfläche drastisch (ein Angreifer kann nicht einfach Zugangsdaten weiterleiten oder Netzwerkdaten ändern; er müsste den Nutzer in Echtzeit täuschen). Sollte das Betriebssystem kompromittiert sein, stellt die dynamische Verknüpfung zumindest sicher, dass jede Diskrepanz zwischen dem, was sein sollte, und dem, was genehmigt wird, von unserem Backend erkannt wird.

Frage 3: Wenn ein biometrisches Merkmal zum Entsperren des Passkeys verwendet wird, gilt das als ein Faktor oder zwei? Erfüllen wir die 2-Faktor-Regel? Lösung: Ein biometrisches Merkmal allein ist für die SCA nicht ausreichend – es ist nur ein Inhärenzfaktor. Bei einer Passkey-Implementierung ist die Biometrie jedoch nicht allein: Der Besitz des Geräts ist der andere Faktor. Die Biometrie des Nutzers entsperrt den auf dem Gerät gespeicherten privaten Schlüssel. Besitz und Inhärenz sind zwei verschiedene Kategorien. Dies ist analog dazu, wie viele Banking-Apps bereits SCA erfüllen: Sie haben das Telefon (Besitz) und Sie verwenden Ihren Fingerabdruck oder Ihr Gesicht, um die App zu entsperren (Inhärenz). Die EBA hat Kombinationen aus Gerätebindung und Biometrie ausdrücklich als konforme SCA anerkannt. Das Passkey-Szenario ist genau diese Kombination. Wenn der Nutzer anstelle von Biometrie eine PIN zum Entsperren des Passkeys verwendet, handelt es sich um Besitz + Wissen, was ebenfalls konform ist. Wir erzwingen bei allen Passkey-Operationen eine Nutzerverifizierung (d. h. der Nutzer muss jedes Mal Biometrie/PIN angeben), sodass es keine Situation gibt, in der der reine Besitz des Geräts ausreicht. Daher ist jede Zahlungsautorisierung per Passkey ein Zwei-Faktor-Ereignis gemäß den PSD2-Definitionen.

Frage 4: Könnte ein Angreifer eine Passkey-Authentifizierung wiederverwenden oder die dynamische Verknüpfung durch Manipulation von Daten während der Übertragung umgehen? Lösung: Nein. Hier arbeiten Passkeys und dynamische Verknüpfung stark zusammen. Jede WebAuthn-Authentifizierung erzeugt eine einzigartige Signatur, die an die Challenge (die wir pro Transaktion generieren) gebunden und auf unsere Domain beschränkt ist. Ein Angreifer kann diese Signatur nicht für eine andere Transaktion wiederverwenden. Die Signatur selbst enthält die Challenge-Nonce und ist nur für das gültig, wofür sie ursprünglich ausgestellt wurde. Wenn ein Angreifer die Netzwerkkommunikation abfangen würde, könnte er den Betrag oder den Zahlungsempfänger nicht ändern, ohne die Signatur ungültig zu machen (da die Challenge oder der Transaktionskontext nicht mehr übereinstimmen würde). Dies ist praktisch der MITM-Schutz, den wir besprochen haben. Außerdem enthalten Passkey-Signaturen Ursprungsdaten – sie werden nicht verifiziert, wenn sie nicht an unsere exakte Website/App-Herkunft gesendet werden, sodass Phishing oder Weiterleitungen nicht funktionieren. Kurz gesagt, jeder Manipulationsversuch macht den Authentifizierungscode gemäß den Regeln der dynamischen Verknüpfung ungültig. Dies ist tatsächlich sicherer als einige aktuelle OTP-basierte Abläufe, bei denen Nutzer manchmal einen generischen Code genehmigen und das Risiko besteht, dass die Anfrage manipuliert wurde. Mit Passkeys binden wir die Nutzerauthentifizierung kryptografisch an die spezifische Sitzung/Transaktion.

Frage 5: Gibt es bekannte regulatorische Stellungnahmen zu WebAuthn/Passkeys für SCA? Sind wir sicher, dass die Aufsichtsbehörden Passkeys als konform akzeptieren werden? Lösung: Bisher hat die EBA keine expliziten Stellungnahmen zu WebAuthn oder dem Begriff „Passkeys“ in ihren Q&A oder Leitlinien veröffentlicht. Basierend auf den von ihr dargelegten Prinzipien passen Passkeys jedoch eindeutig zu den akzeptablen Methoden. Die EBA-Stellungnahme von 2019 nahm im Wesentlichen Ansätze wie FIDO2 vorweg: Für den Besitzfaktor erwähnen sie explizit den „Austausch von öffentlichen/privaten Schlüsseln“ mit ordnungsgemäßer Gerätebindung als Nachweis des Besitzes. Ein WebAuthn-Passkey ist genau das – ein Paar aus öffentlichem und privatem Schlüssel, wobei die private Hälfte sicher an das Gerät gebunden ist. Sie erwähnten auch eine „von einem Gerät erzeugte Signatur“ als gültigen Besitznachweis. Obwohl sie den Begriff Passkey nicht verwendeten, wird die Methode durch ihre Beispiele abgedeckt. Wir haben auch beobachtet, dass große Zahlungsdienstleister in Europa die Implementierung von Passkeys vorantreiben (z. B. PayPal), was auf ein gewisses Vertrauen hindeutet, dass dies PSD2-konform ist. Dieses Beispiel zeigt, dass Passkeys als Teil konformer SCA-Flows akzeptiert werden, sofern die dynamische Verknüpfung und die allgemeinen Anforderungen erfüllt sind.

Frage 6: Benötigen wir weiterhin eine dynamische Verknüpfung, wenn Passkeys Phishing-resistent sind? Lösung: Ja. Passkeys eliminieren Cross-Origin-Phishing, aber PSD2 schreibt weiterhin die dynamische Verknüpfung für die Auslösung von Remote-Zahlungen vor. Die dynamische Verknüpfung bindet den spezifischen Betrag und Zahlungsempfänger an das SCA-Ergebnis und macht jede Änderung ungültig, wodurch die Integrität der Autorisierung über Phishing hinaus (z. B. MITM/MITB/TPP-Substitution) sichergestellt wird.

Die Lösung von Corbado ist konform mit der dynamischen Verknüpfung und PSD2. Die Anzeige für den Zahler vor der Authentifizierung, die einmalige, an Betrag und Zahlungsempfänger gebundene Challenge, die strikte Server-Verifizierung und der unveränderliche Audit erfüllen zusammen die Anforderungen von RTS Art. 5 an das Bewusstsein des Zahlers, Einzigartigkeit/Spezifität, Ungültigkeit bei Änderungen und Integrität/Vertraulichkeit. Die Faktorunabhängigkeit wird durch gerätegebundenen Besitz und UV (Biometrie oder PIN) gewahrt, was mit den EBA-Leitlinien übereinstimmt.

Im Vergleich zu heutigen OTP/SMS-Methoden bietet Corbado wesentlich bessere Sicherheits- und Nutzerergebnisse: Resistenz gegen Phishing und Relay-Angriffe, Verhinderung von stillschweigender Parametermanipulation, stärkere, unanfechtbare Nachweise und reduzierte Reibung durch On-Device-UV. Restrisiken (z. B. Social Engineering, kompromittierte Geräte) werden durch konkrete Kontrollen gemindert und sind geringer als bei herkömmlichen Methoden. Für das Web kann Corbado SPC einführen, sobald die Plattformunterstützung (insbesondere von Apple) breit verfügbar ist, was einen kryptografischen Nachweis der Anzeige hinzufügt, ohne die Kern-Compliance-Haltung zu ändern.

Kurz gesagt, die Passkey-basierte Transaktionsautorisierung von Corbado erfüllt den Buchstaben und den Geist der dynamischen Verknüpfung nach PSD2 und verbessert die Betrugsresistenz und Überprüfbarkeit im Vergleich zu älteren Ansätzen, während ein klarer Weg zu zukünftigen Verbesserungen (SPC) offenbleibt, während das Ökosystem reift.

In der Praxis erfüllen Passkeys die dynamische Verknüpfung, wenn wir drei Dinge tun: Wir zeigen dem Zahler den Betrag und den Zahlungsempfänger vor der Nutzerverifizierung an; wir generieren einen Authentifizierungscode, der spezifisch für genau diese Details ist; und wir machen den Code bei jeder Änderung ungültig (RTS Art. 5(1)(a–d)). Dies spiegelt die Prinzipien wider, die die Aufsichtsbehörden bereits für lokale Biometrie akzeptieren, mit dem zusätzlichen Vorteil, dass Passkeys betriebssystemnativ sind und über Web- und App-Kanäle hinweg ohne eine zusätzliche App funktionieren. In Kombination mit der Ursprungsbindung zeigen sie keine gefälschten Anfragen an – dem Nutzer werden nur legitime Aufforderungen von der ursprünglichen Website oder App angezeigt.