Posts mit dem Label EBICS-Client werden angezeigt. Alle Posts anzeigen
Posts mit dem Label EBICS-Client werden angezeigt. Alle Posts anzeigen

EBICS: Aller Anfang ist schwer

Es liegt in der Natur der Sache, dass der erste Kontakt, den Neukunden mit EBICS haben, in der Regel die Initialisierung ist. Das ist etwas unglücklich, denn damit werden sie gleich zu Anfang ihrer EBICS-Erfahrung mit dem wahrscheinlich umständlichsten und am wenigsten intuitiven Teil konfrontiert. Und wenn Neukunden erfolgreich mit ihrer eigenen Netzwerktechnik, Proxies, Firewalls und dem TLS gekämpft haben, die Daten aus dem BPD-Blatt brav und richtig in die Anwendung übernommen haben, diese sie hoffentlich möglichst einfach und intuitiv durch das Versenden der zwei Initialisierungsnachrichten geleitet hat, dann werden sie überrascht feststellen, dass sie keineswegs jetzt endlich EBICS nutzen können. Stattdessen müssen sie erstmal einen mehrseitigen INI-Brief ausdrucken, unterschreiben und an ihre Bank schicken. Und warten. Warten, bis der Brief angekommen ist, und ein Bankmitarbeiter die 192 Hexziffern der Hashwerte der drei EBICS-Schlüssel in den Bankrechner eingegeben hat. Womöglich noch nach dem Vier-Augen-Prinzip.

Ist das passiert – und es gibt in der Regel keinen Hinweis, ob und wann das passiert sein könnte – dann können die Neukunden endlich mit EBICS starten. Fast. Vorher müssen sie erst noch die Bankschlüssel abgeholt und deren Hashwerte bestätigt haben, die sie mit denen auf dem BPD-Blatt hoffentlich sorgfältig vergleichen.

Nach dem Trauma der Erstinitialisierung ist der Rest nahezu ein Spaziergang. Die eigenen Schlüssel erneuern sich in vielen Anwendungen auf Knopfdruck. Neue Bankschlüssel können mittlerweile mit den alten unterschrieben und automatsch akzeptiert werden. Richtig unangenehm wird es nur, wenn man – aus welchen Gründen auch immer – gezwungen wird, sich vollständig neu zu initialisieren.

Frankreich, du hast es (ein bisschen) besser

Französische EBICS-Kunden, die diesen Blog lesen, werden sich vielleicht verwundert fragen, wovon ich hier eigentlich schreibe. Netzwerk und TLS sind in Frankreich zwar auch nicht einfacher zu handhaben als anderswo, und das BPD-Blatt muss auch abgetippt werden, aber zumindest der eigentliche EBICS-Schlüsselaustausch ist dank CA-basierter Zertifikate so einfach wie man es sich nur wünschen kann: Der Teilnehmer sendet seine Schlüssel als Zertifikate, die die Bank aufgrund der Unterschrift der ausstellenden Certificate Authority direkt validieren und freigeben kann. Der EBICS-Client kann darum unmittelbar anschließend die Bankschlüssel als Zertifikate abholen. Und wenn diese Zertifikate auch von einer CA ausgestellt wurden und der Client dieser CA vertraut, dann steht der Aufnahme einer EBICS-Kommunikation nichts mehr im Weg.

Diese scheinbare Mühelosigkeit täuscht natürlich ein wenig, denn die Zertifikate fallen ja auch nicht vom Himmel. Der Zertifizierungsprozess ist nicht wirklich simpler als die EBICS-Initialisierung, denn auch hier müssen eine Person und ihre digitale Identität sicher zusammengebracht werden. Der Vorteil ist vor allem, dass der Prozess nicht als Teil von EBICS angesehen und darum nicht dem Protokoll angelastet wird. Und man kann natürlich ein Zertifikat für viele Zwecke benutzen – die EBICS-Initialisierung dagegen gilt immer nur für diesen einen Teilnehmer bei dieser einen Bank.

Das Zertifikate noch andere Probleme mit sich bringen, wie regelmäßige Kosten bei der Erneuerung, das Problem, sich möglichst global auf eine Liste vertrauenswürdiger CAs zu einigen, und interessante Ausfallszenarien, wenn es nur einen allgemein anerkannten Anbieter für die Onlineprüfung von Zertifikaten gibt, will ich hier nur am Rande erwähnen.

Es bleibt also schmerzhaft, aber wir sind der Meinung, dass das nicht so bleiben muss. Uns sind in einem Brainstorming zwei Ideen gekommen, die wir hier vorstellen wollen – auch auf die Gefahr hin, dass sie sich als völlig praxisfern erweisen.

Option 1: Von Angesicht zu Angesicht

Unsere erste Idee geht davon aus, dass der zukünftige EBICS-Nutzer bei seinem Bankberater sitzt, um sich von diesem für EBICS freischalten zu lassen. Während also der Bankberater die notwendigen Daten wie Name und Adresse, Kunden- und Teilnehmer-ID in das System einpflegt, reicht er an einer Stelle seine Tastatur an den Teilnehmer, der ein frei gewähltes Einmalpasswort eintippt – wie üblich zwei Mal, um Vertipper auszuschließen. Das Passwort muss der Teilnehmer sich merken, bis er sich an seinem EBICS-Client anmeldet, und dann bei der Einrichtung des Bankzugangs wieder eingeben. Mit Hilfe des Passworts wird dann ein symmetrischer Schlüssel generiert, mit dem die Initialisierungsnachricht – die alle drei EBICS-Schlüssel enthält – verschlüsselt wird. Da der Bankrechner das Passwort kennt, kann er denselben symmetrischen Schlüssel generieren, und die Kommunikation ist gegen Abhören, Manipulation und sogar Man-in-the-Middle-Attacken gesichert. Deswegen kann der Server auch direkt in der Antwort die Bankschlüssel zurückgeben. Das Initialisierungspasswort wird nicht weiter benötigt (und darf auch nicht für spätere Wiederinitialisierungen wiederverwendet werden).

Das Ergebnis: eine einzige EBICS-Nachricht, nach der der Teilnehmer vollständig initialisiert und bereit für EBICS ist. Auf der Bankseite entfallen nach der Einrichtung die manuellen Schritte, der Kunde muss keinen Brief schicken und – vor allem – nicht warten!

Zwei mögliche Probleme fallen uns dabei ein:

  1. Ein Angreifer, der sowohl die Bank als auch den Teilnehmer gut genug kennt, könnte Kunden-ID und Teilnehmer-ID sowie das Passwort, das der Kunde sich ausgedacht hat, erraten und sich selber vor dem legitimen Teilnehmer anmelden. Dagegen kann z. B. eine PIN, die bei der Einrichtung des Teilnehmers generiert wird und diesem mitgegeben wird, sowie eine Sperre nach n Fehlversuchen schützen.
  2. Die Fehler, die der Server zurückmeldet, wenn jemand den Schlüssel wild rät, könnten Orakelattacken ermöglichen. Auch hier sollte es helfen, wenn nach n Fehlversuchen der Teilnehmer komplett gesperrt wird.

Das ließe sich also lösen.

Option 2: Total digital

Die Option 1 ist ja noch ein bisschen im Bisherigen verhaftet: Der Kunde bekommt ein Blatt Papier, die Daten daraus tippt er in seine Anwendung … Warum eigentlich? Warum nicht dem Kunden stattdessen die Daten digital geben? Z.B. als USB-Stick, der vom Bankberater direkt bespielt und dem Kunden überreicht wird, der ihn anschließend gerne behalten darf, natürlich mit Werbeaufdruck der Bank. Auf dem USB-Stick wäre dann eine Datei, die alles das enthält, was man für die Einrichtung braucht:

  • die URL
  • die IDs
  • einen symmetrischen Schlüssel, mit dem ich analog zur Option 1 die initiale Kommunikation absichere

Hier muss natürlich keine Rücksicht darauf genommen werden, was ein Mensch sich merken kann oder abtippen will, der Schlüssel kann beliebig lang gewählt werden. Der Angriff über das Erraten des Schlüssels fällt damit weg. Das größte Risiko ist noch, dass der Kunde den USB-Stick auf dem Weg nach Hause verliert. Aber dagegen kann auch wieder eine Passwortsicherung der Datei helfen.

Wenn er aber heile mit dem Stick zu Hause ankommt, importiert er die Datei in seine EBICS-Anwendung. Diese erkennt das Format und kann damit sofort und autonom den kompletten Bankzugang einrichten – wie bei Option 1 beschrieben.

Wenn mein System jetzt keinen USB-Eingang hat? Dann ist es entweder ein Smartphone, auf dem ich mich z. B. für eine Signatur-App anmelden will. In dem Fall kann es zwar vielleicht nicht so viel mit USB, aber jede Menge mit QR-Codes anfangen. Also gibt man ihm die Daten eben auf diesem Weg. Vielleicht ist es aber auch Firmenpolitik, dass keine USB-Sticks verwendet werden dürfen, nicht einmal aus so einer vertrauenswürdigen Quelle wie meiner Bank. Dann könnte man natürlich auf den Gedanken kommen, sich die Datei einfach per Mail zuzusenden. Und wenn man den Gedanken erst mal hatte, fragt man sich, ob es denn überhaupt einen USB-Stick braucht. Und die Antwort ist vermutlich nein, wenn (a) die Datei mit einem ausreichend guten Passwort kryptographisch einwandfrei gesichert wird und (b) das Passwort nicht in derselben Mail steht, sondern auf einem anderen, sicheren Weg übermittelt wird. Das sollte zu schaffen sein.

Der Weg zum Ziel

Die Initialisierung lässt sich vereinfachen. Damit diese Vereinfachung aber was nützt, reicht es nicht, wenn nur eine Bank sie umsetzt oder – noch absurder – nur ein Kundensystem(-hersteller). Nur wenn so eine Änderung Teil der EBICS-Spezifikation wird, kann sie den Kunden und den Banken das Leben erleichtern. Dann aber ganz erheblich: Für den Kunden wird das Einrichten eines Bankzugangs vom Ärgernis zu einer Nebensächlichkeit, und die Banken können sich das Abtippen von Hashwerten sparen. Man hat ja schon von Büros in Callcentern gehört, in denen die Mitarbeiter nichts anderes machen.

Wenn die Initialisierung so sehr vereinfacht wird, ist es vielleicht auch gar kein Problem mehr, dass sie ja für jeden EBICS-Teilnehmer einzeln durchgeführt werden muss. Aber auch hier haben wir uns Gedanken zur Vereinfachung gemacht, die ich in einem späteren Blog-Post vorstellen möchte.


Autor: Curd Reinert

Echtzeitbenachrichtigungen und EBICS - Schluss mit den „Hoffnungsabfragen“ bei Downloads

Wie bereits in meinem Blog-Beitrag im Dezember 2018 vorgestellt, findet auch das Thema Echtzeitüberweisungen (Instant Payments) im Firmenkundengeschäft über das neue Bulk-Format Einzug in die EBICS-Welt. Für die Einreichung von Echtzeitüberweisungen gelten dabei für die EBICS-Transferphase nicht die engen synchronen Zeitregeln des Instant Payments. Die Uhr beginnt erst hinter dem EBICS-Bankrechner zu ticken.

Und wie sieht es mit der Rückrichtung für Instant-Payments-Geschäftsvorfälle im EBICS aus? Immerhin sollte ein Geld-Eingangsbenachrichtigung (Credit Notification), wenn schon nicht in Echtzeit möglich, dennoch möglichst zeitnah dem Zahlungsempfänger zugeführt werden. Im Standard-Rollenverhältnis in der Kunde-Bank-Beziehung holt der EBICS-Client bekanntlich stets die Informationen vom Bankrechner ab. Ein aktiver Versand durch die Bank per EBICS ist hier nicht vorgesehen. Hier hat insbesondere die Wirtschaft die Banken und Die Deutsche Kreditwirtschaft zu einer pragmatischen Lösung einer Push-Möglichkeit gedrängt. Ziel sollte es letztendlich sein, eine Lösung zu entwickeln, die sich ohne Änderungen des EBICS-Protokolls und ohne Veränderung des Rollenverhältnisses umsetzen lässt.

Herausgekommen ist die Idee einer neuen Websocket-basierten Standardschnittstelle, die EBICS-Clients über die Bereitstellung von neuen Informationen für den Download informiert. Hierzu gehört auch die Information über eine neue Bereitstellung einer Credit Notification. Auf diesem neuen Push-Kanal werden somit keine sensiblen Daten übertragen. Die Abholung der relevanten sensiblen Daten erfolgt nach wie vor über den sicheren EBICS-Kanal.

Mittlerweile hat Die Deutsche Kreditwirtschaft diese neue Schnittstelle in der “Spezifikation Echtzeitbenachrichtigungen” spezifiziert und in der Version 1.0 am 18.07.2019 auf der deutschen EBICS-Webseite (www.ebics.de) veröffentlicht.

Nun gilt es, diese Schnittstelle in den EBICS-Clients und in den EBICS-Bankrechnern standardkonform und zeitnah umzusetzen. Bieten sich dadurch doch neue Möglichkeiten zur Optimierung des Firmenkundengeschäftes auch unabhängig vom Instant Payments. So lassen sich z. B. für sämtliche Abholprozesse die häufigen und permanenten “Hoffnungsabfragen” von automatisierten EBICS-Clients einsparen, wie sie u. a. bei Kontoauszugsabrufen durchgeführt werden. Dadurch können sowohl EBICS-Client-Nutzer als auch Bankrechnerbetreiber mit Lastreduzierung rechnen. Das sind doch gute Neuigkeiten, oder?

Autor: Michael Lembcke

EBICS-Tests mit Kunden im produktiven Bankrechner?

Seit EBICS 2.4 ist es in Frankreich möglich, Geschäftsvorfälle – nicht wie u. a. in Deutschland üblich – über dreistellige Auftragsarten sondern über die bis zu 40-stelligen FileFormat-Parameter auszutauschen. Diese sind bekanntlich jeweils mit den Auftragsarten FUL bzw. FDL einzuleiten. Dabei ist es möglich, ein sogenanntes Test-Flag anzugeben. Darüber kann ein EBICS-Kunde im produktiven Betrieb z. B. beim Senden einer Datei der Bank eine Testeinreichung signalisieren. Vorausgesetzt, es besteht eine bilaterale Vereinbarung über die Nutzung des Test-Flags, kann die Bank den Auftrag annehmen, als Testfall werten und vor der echten Verarbeitung aussteuern. Die Nutzung eines Test-Flags in Produktion ist bei den Banken nicht unumstritten. Eine solche Option wird von deutschen Banken derzeit überwiegend abgelehnt.

Mit der aktuellen EBICS-Version 3.0 und der einheitlichen Nutzung der BTFs anstelle von Auftragsarten und FileFormat-Parametern entfällt das bestehende Test-Flag in der EBICS-Spezifikation. Zudem wurde mit dem EBICS-CR EB-17-01 Element Group Parameter eine verschärfte Prüfung auf die Nutzung von nicht bilateral vereinbarten Angaben in den generischen Parametern des BTFs eingeführt. Unerlaubte Angaben werden nun mit dem EBICS-Returncode 09-0-0-06: EBICS_UNSUPPORTED_REQUEST_FOR_ORDER_INSTANCE abgelehnt.

Als Hilfestellung für die EBICS-3.0-Einführung in Frankreich hat der französische CFONB einen eigenen Migrationsleitfaden erstellt (EBICS 3.0 Aide à la migration BTF & Table de correspondance File Format/BTF). Da in Frankreich das Test-Flag von Banken in der Vergangenheit genutzt wurde und auch weiterhin der Bedarf an einer solchen Option besteht, hat der CFONB für die BTF-Migration die Nutzung des Test-Modus für BTF definiert und als optionale Funktion in den Leitfaden aufgenommen. Somit kann bei bilateraler Vereinbarung zwischen Bank und Kunde auch bei BTF der Parameter TEST für Testfälle genutzt werden. Bei abweichender Parameterangabe erfolgt eine Ablehnung mit dem o. g. Returncode. EBICS-Bankrechner, und EBICS-Clients können diese Funktion optional mit anbieten.

Unabhängig davon gibt es bei EBICS auch die Alternative, für Testeinreichungen eigene speziell für den Test bilateral vereinbarte Geschäftsvorfälle (BTFs) zu nutzen.

Letztendlich bleibt aber festzuhalten, dass bei Nutzung der Testoption in der Produktionsumgebung immer das Risiko besteht, dass Testdateien die Produktion negativ beeinflussen oder gar unerwartet Eingang in die Produktionsdaten finden können.

Sicherer ist da dann doch eine eigene EBICS-Bankrechner-Installation für EBICS-Tests mit Kunden. Warum nicht?


Autor: Michael Lembcke

Sie sind Bankkunde und nutzen EBICS: Funktioniert Ihr EBICS-Monitoring auch noch mit EBICS 3.0?

Für das Monitoring der EBICS-Prozesse und -Ergebnisse steht seit EBICS 2.5 den EBICS-Clients neben dem rein textbasierten Kundenprotokoll auch ein XML-basiertes Protokoll für das fachliche EBICS-Monitoring zur Verfügung. Letzteres eignet sich insbesondere für maschinelle Auswertungen. Das textbasierte Protokoll kann durch den EBICS-Client mit der Auftragsart PTK und das XML-basierte Protokoll mit der Auftragsart HAC vom EBICS-Server heruntergeladen werden. Mit EBICS-Version 3.0 ist das textbasierte Protokoll nicht mehr Bestandteil der Spezifikation. Zudem gibt es Änderungen im HAC-Protokoll, die bei der maschinellen Ergebnisauswertung zu berücksichtigen sind. Diese Änderungen wirken sich wegen der erforderlichen übergreifenden Versionsinteroperabilität z. T. auch auf EBICS-Clients niedriger EBICS-Versionen aus, sobald ein EBICS-Bankrechner EBICS Version 3.0 unterstützt.

Für Software-Hersteller und EBICS-Nutzer gilt daher, dass man sich bei den EBICS-Clients, die bereits über Funktionen der maschinellen Kundenprotokoll-Auswertung verfügen, auf Änderungen einstellen muss. Zunächst sollte für maschinelle Auswertungen in EBICS-Clients der Wechsel vom PTK zum HAC vollzogen werden. Außerdem gilt für diejenigen, die bereits das HAC-Protokoll nutzen, dass mit EBICS 3.0 das finale Ergebnis im HAC-Protokoll anders abgebildet wird.

Bisher informierte das HAC-Ende-Kennzeichen mit den Angaben ORDER_HAC_FINAL_POS und ORDER_HAC_FINAL_NEG direkt darüber, ob das Ergebnis der Einreichung positiv oder negativ war. Mit EBICS 3.0 gibt es lediglich noch ein HAC-Ende-Kennzeichen ORDER_HAC_FINAL, welches den Ausgang der Einreichung ausschließlich in Verbindung mit dem letzten Reason Code ausdrückt. Demnach weist dann beispielsweise der finale Code DS04 darauf hin, dass der Auftrag abgelehnt wurde und DS05, dass der Auftrag erfolgreich eingereicht und an die Banksysteme weitergeleitet wurde. Weitere Reason Codes sind zu berücksichtigen.

Also, damit Ihr EBICS-Monitoring auch weiterhin die korrekten Ergebnisse liefert, empfehle ich auf das HAC-Kundenprotokoll zu setzen und sich auf die Auswertung der Reason Codes zu konzentrieren. So behalten Sie auch zukünftig den Überblick in der EBICS-Kommunikation mit Ihrer Bank.


Michael Lembcke