EBICS-Security – Wann ist es Zeit für das Update Ihres Kundensystems?

Mit EBICS sind verschiedene Sicherheitsfunktionen und -vorgaben spezifiziert, die von Kunden und Banken einzuhalten sind. Die Bank muss stets darauf achten, dass die aktuellen Vorgaben in ihrem EBICS-Bankrechner angeboten und unterstützt werden. Aber auch der EBICS-Kunde und der einzelne EBICS-Teilnehmer selbst sind dafür verantwortlich, stets Kundensoftware einzusetzen, die den aktuellen EBICS-Sicherheitsstandards entspricht. Daher sind nicht nur aufgrund von funktionalen Anpassungen, sondern auch aus Sicherheitsgründen regelmäßige Softwareupdates der EBICS-Clientsysteme unerlässlich.

Ist eine bestehende EBICS-Clientsoftware schließlich durch Updates auf den neuesten Stand gebracht, heißt das jedoch nicht, dass diese EBICS-Software dann auch automatisch über die aktuellste EBICS-Version und das neueste Sicherheitsverfahren mit der Bank kommuniziert. Je nach zuvor genutzter EBICS-Version und Clientfunktionalität müssen dazu erst noch die verschiedenen Applikationsschlüssel für Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) sowie die neu zu nutzende EBICS-Version aktualisiert und mit dem oder den EBICS-Bankrechnern ausgetauscht werden. Zudem könnte es erforderlich sein, die Internetverschlüsselung (TLS) durch einen neuen Zertifikatsaustausch auf eine neuere und sichere Version zu aktualisieren. Diese Art von Aktualisierungen erfordern i.d.R. aktives Handeln und manuelle Eingriffe des EBICS-Teilnehmers.

Warum sind diese Aktualisierungen wichtig?

Für die EBICS-Kommunikation über das Internet sind eigene Sicherheitsverfahren spezifiziert. Diese werden von der EBICS-Gesellschaft im Laufe der Zeit mit neuen EBICS-Versionen immer wieder aktualisiert und an die aktuellen Sicherheitsbedürfnisse angepasst. Ein Beispiel stellen die Schlüssellängen dar. So sind für die Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) in älteren EBICS-Versionen noch Schlüssellängen von 1.024 Bit zulässig. Diese Länge entspricht nicht mehr den aktuellen Sicherheitsanforderungen, denn zu kurze Schlüssel gelten als unsicher. Neuere EBICS-Versionen hingegen lassen derzeit nur Schlüssel mit einer Mindestlänge von 2.048 Bit zu. Ein anderes Beispiel sehen wir bei den genutzten Verfahren und Versionen der TLS-Verschlüsselung. Um Sicherheitsempfehlungen, wie z. B. den Empfehlungen des BSI in Deutschland flexibler folgen zu können, hat die EBICS-Gesellschaft für EBICS 3.0 die entsprechenden Vorgaben in einem eigenen Anhang Transport Layer Security zur Spezifikation ausgelagert. Da rückwirkend die Spezifikation zu EBICS 2.5 nicht angepasst werden konnte, hat die DK (Die Deutsche Kreditwirtschaft) 2019 unter dem Titel Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen zudem ein eigenes Empfehlungsschreiben zu den in EBICS zu nutzenden Sicherheitsverfahren herausgegeben. Siehe hierzu auch www.ebics.de und www.ebics.org.

Um den EBICS-Teilnehmern einen weichen Umstieg auf neuere EBICS-Versionen und Sicherheitsstandards zu ermöglichen, bieten die meisten Banken ihren Kunden jedoch parallel noch die älteren Verfahren an. Leider lässt sich feststellen, dass von Kunden dann aber die Gelegenheit zur EBICS-Aktualisierung in vielen Fällen nicht genutzt wird. Viele verharren auf älteren Systemen und Verfahren. Damit fällt es dann wiederum den Banken, schwer die alten Verfahren abzuschalten.
Am Ende erwartet jeder Beteiligte in der EBICS-Kommunikation, dass ein sicherer Datenaustausch gegeben ist. Einen Schaden möchte niemand erleiden. Also sollte auch jeder dafür Sorge tragen, dass er seinen Teil dazu beträgt. Natürlich ist die EBICS-Sicherheit nicht das Einzige, was Banken und Firmenkunden im Auge halten müssen. Letztendlich müssen heutzutage alle Beteiligten in ihrer Infrastruktur und ihren Softwarelösungen alle erdenklichen Sicherheitsmaßnahmen ergreifen, um Missbrauch und Schaden vorzubeugen.

Also warum noch warten? Gehen wir es an.

Autor: Michael Lembcke

Weiterlesen

Open Banking: EBICS versus API

Open Banking ist einer der Megatrends, den viele Banken angeblich zu verschlafen drohen. Weil kaum eine PSD2-Schnittstelle marktreif zu sein scheint, hat die Bankenaufsicht jetzt bis Dezember 2020 eine Übergangsfrist eingeräumt. Doch das Problem liegt woanders: Viele Institute verspüren nur wenig Lust, viel Geld in die Hand zu nehmen, um Anbietern von Open-Banking-Schnittstellen das Leben zu erleichtern – zumal etablierte Protokolle wie FinTS und EBICS viel mehr leisten als die „APIisierung“ des Bankgeschäfts bisher hervorgebracht hat.

Beide Protokolle, FinTS und EBICS, umfassen heute schon fast alle Bereiche des Bankings, vom Zahlungsverkehr über den Wertpapierhandel bis hin zum Kreditgeschäft. Insgesamt stehen weit mehr als 200 Prozesse bereit, die sowohl die fachlichen Schnittstellen verbindlich beschreiben als auch die technische Kommunikation der beteiligten Partner untereinander. Seit den 90er-Jahren geben HBCI und FinTS bereits die Richtung für offene Standards in der Kommunikation mit Banken vor. EBICS ist von der Deutschen Kreditwirtschaft (DK), beziehungsweise deren Vorläufer, schon vor mehr als zehn Jahren als verbindlicher Standard für die Kommunikation mit Firmenkunden eingeführt worden. Open Banking ist also seit vielen Jahren bereits Realität in Deutschland.

Keine einheitliche PSD2-Schnittstelle in Sicht

So gut die Idee von Open Banking auch ist. Die auch durch PSD2 forcierte Debatte lässt viele Banken, selbst die willigen, ratlos zurück. Einerseits soll unter anderem durch PSD2 ein Open-Banking-Standard für ganz Europa entstehen. Andererseits hat der Gesetzgeber bewusst offengelassen, wie die Kommunikation genau stattfinden soll und wie sie abzusichern ist. Die Folge: Anbieter von Open-Banking-APIs drängen die Banken dazu, ihre Lösungen zu implementieren und ihre ureigenen Interpretationen von Open Banking zu übernehmen, nur um ja nichts zu verpassen. Hinzu kommt, dass verschiedene Initiativen in den unterschiedlichen Ländern Protokolle zur technischen/fachlichen Nutzung entwickeln, die zu einem Wildwuchs an API-Dialekten führen werden. Länderübergreifende Konzeptionen dagegen sind noch bei weitem nicht in Sicht.

All dies kann sich für die Institute zu einem Fass ohne Boden entwickeln, wenn nicht bald eine einheitliche PSD2-Spezifikation vorliegt, an der sich jede Bank orientieren kann. Solange das nicht passiert, dürften viele Open-Banking-Träumereien unerfüllte Wünsche bleiben. Denn die Öffnung hat per Gesetz kostenlos und frei von Diskriminierung zu erfolgen. Damit Geld verdienen wollen andere. Was also soll die Motivation für eine Bank sein, immer neue API-Dialekte kostenfrei anzubinden, nur damit Drittanbieter ihre Apps leichter unter das Volk mischen können? Damit degradieren sich die Institute selbst zum reinen Serviceanbieter. Viel naheliegender ist doch, auf längst etablierte Standards zurückzugreifen.

EBICS: Open Banking für Firmenkunden

Einer dieser Standards ist EBICS. Und dieser Standard ist weit verbreitet: Neben Deutschland spricht auch Frankreich EBICS. Zwischen der Deutschen Kreditwirtschaft und ihrem französischen Pendant, dem CFONB, besteht ein Kooperationsabkommen. Diese beiden größten Zahlungsverkehrsmärkte in Euroland decken das Firmenkunden- und das Interbankengeschäft mit EBICS ab. Die Schweiz (SIX) zählt ebenfalls zu den EBICS-Fans. Österreich (STUZZA) überlegt einzusteigen. Statt im API-Sumpf unterzugehen, lohnt es sich zu fragen, wie sich EBICS PSD2-konform ausbauen lässt. Die Antwort: mit einer Fernsignatur (vgl. Abb.1). Ein modernes EBICS-Portal kann aus eingehenden Daten wie dem Code einer PhotoTAN oder einer QR-TAN Hardware-basiert die Signatur erstellen und an den EBICS-Bankrechner senden.

Abb. 1: Wie Fernsignaturen EBICS zu einer PSD2-konformen Open-Banking-Lösung erweitern

EBICS bietet Firmenkunden viele Vorteile. Unternehmen, die über einen EBICS-Client verfügen, können sicheres Multibanking betreiben und auch die Verteilte Elektronische Unterschrift nutzen (VEU). Damit lassen sich Rollen- und Rechtemodelle abbilden (Signaturen T, A, B und E), um etwa zu bestimmen, ob eingereichte Zahlungsaufträge von autorisierten Personen stammen und ob die jeweilige Person über die entsprechenden Berechtigungen verfügt, um diese Zahlungsaufträge freizugeben. Ähnlich wie bei FinTS gilt auch für EBICS: Die nötige Infrastruktur, um Open Banking zu verwirklichen, existiert bereits. Schon allein deshalb lässt sich nachvollziehen, dass viele Institute damit hadern, jetzt zu investieren. Niemand garantiert, dass sie sich für den richtigen API-Anbieter entscheiden oder dass der Gesetzgeber keine neuen Vorschriften erlässt, die bereits getätigte Investitionen obsolet machen.

Linktipps:
•    Erwartung trifft auf Realität: PSD2 Schnittstellen sind weiterhin nicht marktreif
•    Open Banking: Mit FinTS und EBICS gegen den API-Wildwuchs (PSD2/XS2A-Lösung)

Autor: Michael Schunk

Weiterlesen