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:
- 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.
- 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
