EBICS und PSD2 – Wie kommt das zusammen?

Die Zahlungsdiensterichtlinie PSD (Payment Services Directive) des Europäischen Parlaments ist die rechtliche Grundlage für den EU-weiten einheitlichen Binnenmarkt im Zahlungsverkehr. Die aktuelle Version PSD2 wurde am 23.12.2015 im Amtsblatt der Europäischen Union veröffentlicht und muss bis zum 13.01.2018 in nationales Recht umgesetzt sein. Welche Auswirkungen hat die PSD2 auf EBICS?


Ziele der PSD2 sind insbesondere:
  • strengere Sicherheitsanforderungen an den elektronischen Zahlungsverkehr
  • Schutz der Finanzdaten von Verbrauchern
  • Öffnung des Markts für Zahlungsverkehrsdienstleister, insbesondere bei den Diensten für Verbraucher und Unternehmen
  • Stärkung der Verbraucherrechte, z. B. bei der Haftung für nicht autorisierte Zahlungen und Erstattungen bei Lastschriften in Euro
  • Untersagung der Berechnung von Aufschlägen, unabhängig vom Zahlungsinstrument
Strengere Sicherheitsanforderungen an den elektronischen Zahlungsverkehr fordern, dass der Zugriff auf Kundenkonten sicher ist. Die Identifikation eines Zahlungsdienst-Nutzers oder einer Transaktion erfordert eine starke Authentifizierung. EBICS erfüllt diese Voraussetzungen mit den asymmetrischen benutzerbezogenen Schlüsselverfahren. Der praktischen Umsetzung einer starken Authentifizierung steht somit nichts entgegen.

Die drei Grundpfeiler einer starken Authentifizierung sind bekanntlich Besitz, Inhärenz und Wissen. Mindestens zwei dieser Kriterien sind den Nutzern beim Zugang zur EBICS-Autorisierung anzubieten. Beispielsweise ermöglicht eine Chipkarte (Besitz) als EBICS-Schlüsselmedium über einen Chipkartenleser per PIN-Eingabe (Wissen) eine Autorisierung. Dies muss in der Schnittstelle zum Nutzer also client-seitig umgesetzt sein.

Neben den EBICS-Mitteln zur eindeutigen Identifikation und Authentifizierung der Person kann die Bank zusätzliche verstärkende Prüfungen vorsehen (Inhärenz), z. B. ob in der Kommunikation die zuvor vereinbarten IP-Adressen genutzt werden. Eine nicht passende IP-Adresse verhindert bei ansonsten passender Authentifizierung den Zugang.

Die geforderte Dynamik in der Authentifizierung bildet EBICS durch das elektronische Signaturverfahren ab, denn die Signatur wird stets über den Hashwert der Originaldatei und einen Timestamp gebildet.

Zudem ermöglicht es die EBICS-Funktion der Verteilten Elektronischen Unterschrift (VEU), auf Seiten der Zahlungsdienst-Nutzer die Infrastrukturen für Zahlungseinreichungen und Autorisierungen zu trennen. So kann z. B. die Einreichung über einen Automaten per EBICS unautorisiert erfolgen und die vorgeschriebenen Autorisierungen nachträglich per Mobile-App, EBICS-Portal oder mit sonstigen EBICS-Clients, also räumlich und zeitlich getrennt. Außerdem können die Autorisierungsbedingungen vorschreiben, dass mehrere Personen beteiligt sind. Dies bieten heutige EBICS-Lösungen wie EBICS-Portale, EBICS-Browserlösungen, EBICS-Mobile-Clients sowie sonstige EBICS-Clients bereits. Es gilt, diese Techniken für die PSD2 konsequent anzubieten und zu nutzen.

Den Zahlungsverkehrsmarkt für Zahlungsverkehrsdienstleister zu öffnen, bedeutet, dass Banken den Anwendungen von Drittanbietern den Zugang zu Kundendaten geben müssen – wenn der Kunde dem zustimmt. Um diese Anforderung umzusetzen, sind Schnittstellen gefragt. Eine nutzbare Schnittstelle bietet der EBICS-Standard selbst. Sofern der Drittanbieter sich die Informationen nicht direkt über den Standard-EBICS-Zugang beschaffen kann, sind u. a. schnelle und flexible APIs gefragt, die die geforderten Daten bedarfsgerecht austauschen. Dabei sind Einheitlichkeit und Mehrfachnutzbarkeit wünschenswert.

In der Praxis werden Nutzeraktivitäten und insbesondere Autorisierungen in E-Banking- und ZV-Anwendungen bereits aufgezeichnet. Die mit der PSD2 angestrebte Stärkung der Verbraucherrechte fordert allerdings von den Dienstleistern und Banken, die Zahlungsverkehrsabläufe und Autorisierungen im Nutzerkontext nachvollziehbar und nachweisbar möglichst vollständig zu protokollieren und aufzubewahren. Dies gilt im Kontext von EBICS für Banken, aber auch für Diensteanbieter, die z. B. EBICS-Client-Anwendungen betreiben.

Zusammengefasst hat die PSD2 zunächst keinen direkten Einfluss auf die EBICS-Spezifikation selbst. Allerdings müssen EBICS-Nutzer die PSD2 im Nutzungskontext berücksichtigen. Die Anforderungen der PSD2 sind also für den Betrieb und die Nutzung von EBICS-Lösungen frühzeitig zu definieren und umzusetzen. Die Zeit läuft.

Michael Lembcke

“Offline Zahlungs-Software im Visier von Hackern – Schweizer Unternehmen betroffen”

Obige Schlagzeile ist der Mitteilung der Melde- und Analysestelle Informationssicherung MELANI im Juli dieses Jahres entnommen. Sie beschreibt eine neue Art von Hacker-Angriff auf Unternehmen in der Schweiz.

Firmen verwenden heute für die Abwicklung von Massenzahlungen, insbesondere bei Multibank-Verbindungen, in der Regel eine sog. Offline-Software für die Übermittlung, Freigabe und Ausführung von elektronischen Zahlungsaufträgen. Dabei werden Überweisungen automatisiert direkt aus der ERP-Software ausgelöst und über sichere Protokolle an die Bank übermittelt. Diese Art der Zahlungsverkehrsabwicklung macht den Großteil der heute in der Schweiz elektronisch eingereichten Aufträge aus.


Die in der Meldung von MELANI beschriebene Schadsoftware „Dridex“, die sich über schädliche Microsoft Office Dokumente in E-Mails von vermeintlich legitimen Absendern verbreitet, fokussiert seit neuestem genau diese Offline-Software-Lösungen. Dabei werden gezielt Hersteller attackiert, die im Schweizer Markt eine gewisse Verbreitung haben. Viele Firmen sind aktuell etwas verunsichert, wie sicher ihre Lösung in Tat und Wahrheit noch ist und wie sie sich gegen ähnliche Hacker-Angriffe schützen können.

Zunächst gelten einmal die von MELANI seit langem publizierten Sicherheitshinweise wie Verwendung dedizierter Computer, Ignorierung von Mails mit verdächtigen Attachments, regelmäßige Aktualisierung von Betriebssystemen und Virenschutzprogrammen etc., um die Absicherung der eigenen Infrastruktur zu gewährleisten. Ein Hinweis fällt dabei ins Auge, nämlich der, dass Kollektiv- anstelle von Einzelunterschriften eingesetzt werden sollen. Wie funktioniert das in der Praxis, wo ja keine Papier-Aufträge mehr physisch von den Bevollmächtigten der Firma signiert und an die Bank versendet werden?

Die Banken bieten hier grundsätzlich zwei Lösungen an (teilweise auch in Kombination). Einerseits ist die Freigabe über einen anderen Kanal möglich. Das heißt, die Datei mit den Zahlungsaufträgen wird beispielsweise über das Protokoll EBICS (Electronic Banking Internet Communication Standard) direkt aus der Offline-Software an die Bank übermittelt, wobei der Auftrag aber noch nicht zur Ausführung autorisiert wurde. Mittels Freigabe im Online-Banking der Bank können die Aufträge dann definitiv von einer zweiten Person freigegeben werden.

Eine weitere, sichere und flexible Art der Kollektiv-Unterschrift ist der Einsatz der im EBICS-Standard enthaltenen „Verteilten elektronischen Unterschrift“ (VEU). Der Standard sieht hierbei die Unterschriften-Modelle „Transport“- (keine Autorisierung), „Einzel“-, „Kollektiv A“- und „Kollektiv B“-Unterschriften vor. Pro Auftrag kann zudem auf Seiten der Bank ein Tageslimit definiert werden (wahlweise pro Kunde, Konto und Auftragsart). Die VEU erlaubt dem Kunden eine 1:1 Abdeckung der Unterschriftenregelung seiner Unternehmung und führt in Verwendung mehrerer Kanäle (z. B. Erteilung der zweiten Unterschrift über ein Mobile Device) zu einem sehr hohen Sicherheitsniveau.
Immer mehr Banken in der Schweiz führen die EBICS VEU als Angebot ihrer E-Banking-Lösungen ein. Erkundigen Sie sich bei Ihrem Institut explizit danach oder stellen Sie Ihre Fragen an info@ppi.ch, wenn Sie noch mehr Information zur EBICS VEU benötigen.

Original-Meldung MELANI: https://www.melani.admin.ch/melani/de/home/dokumentation/newsletter/offline-payment-software.html

Carsten Miehling 

EBICS mobil – jederzeit und überall

Michael Schunk, Product Manager, PPI AG

Das EBICS-Protokoll ist dafür ausgelegt, große Datenmengen zu übertragen, Kontoinformationen abzurufen und Aufträge zu autorisieren. Das sind die Grundbedürfnisse eines Schatzmeisters, die EBICS erfüllt und die den Erfolg von EBICS garantieren.
Im Zeitalter der Digitalisierung werden immer mehr Informationen immer schneller bereitgestellt. Dieser Anforderung kann sich auch EBICS nicht entziehen. Die Antwort darauf sind mobile EBICS-Apps, die den Kunden schnell informieren.

Der Geschwindigkeitsvorteil von EBICS-Apps resultiert aus zwei Aspekten:
  • Push-Nachrichten
    Gezielte Push-Nachrichten ersparen dem Nutzer die Abfragen. Er wird aktiv über ein Ereignis informiert, z. B. eine Freischaltung oder einen Zahlungseingang.
  • Ortsunabhängigkeit
    Smartphones erlauben einen fast grenzenlosen Zugriff auf Informationen. So kann man eine EBICS-Signatur beispielsweise während eines Meetings leisten.
Die ersten EBICS-Apps hatten gravierende Fehler, die einem den Gebrauch vermiesen:
  • Download
    Um eine Datei zu unterschreiben, muss die gesamte Datei heruntergeladen werden. Das können viele Megabytes sein. Dabei vergeht einem jede Lust am Unterschreiben, und das monatliche Download-Volumen ist schnell aufgebraucht.
  • Performance
    Beim Abruf der Kontoinformation muss eine XML-CAMT-Nachricht zuerst analysiert (neudeutsch: geparst) werden. Die kleine CPU des Smartphones zieht dabei so viel Strom, dass der Akku heiß wird und sich schnell entleert. In der Wartezeit kann man nicht einmal Mails abrufen, da das Smartphone voll ausgelastet ist.
  • Sicherheit
    Alle drei EBICS-Schlüssel werden auf dem Smartphone oder auf einem Server gehalten. Wird das Smartphone gestohlen, sind Angriffen Tür und Tor geöffnet. Die Schlüssel auf dem Server zu speichern, widerspricht allen Sicherheitsanforderungen.
Achten Sie beim Kauf von EBICS-Apps auf diese Kinderkrankheiten. Es sind immer noch zu viele davon auf dem Markt.

Doch zurück zum Schatzmeister. Was benötigt dieser?
  • aktuelle Informationen über Zahlungseingänge und -ausgänge
  • Autorisierung von Zahlungen
  • aktive Benachrichtigung, z. B. bei Freischaltungen oder erwarteten Zahlungseingängen
Der Schatzmeister will und muss stets auf dem Laufenden sein. Was mit klassischen EBICS-Kundensystemen noch unmöglich erscheint, wird durch EBICS-Apps Realität. Push-Services benachrichtigen den Kunden aktiv. Ist der Kunde nicht unterwegs oder möchte keine Push-Nachrichten empfangen, kann er per E-Mail informiert werden.

Die Abbildung zeigt die neue EBICS-App der HSH Nordbank für ihre Firmenkunden. Immer mehr Banken nutzen die digitalen Möglichkeiten und machen damit EBICS noch attraktiver.

Michael Schunk

Hacker-Angriffe auf den SWIFT-Zahlungsverkehr

81 Millionen US-Dollar – diese Riesensumme haben Kriminelle von der Zentralbank Bangladesch gestohlen. Nicht bei einem filmreifen Überfall, sondern ganz still mit einem Hacker-Angriff. Die Diebe veranlassten mehr als 30 Überweisungen vom Konto der Bangladesh Bank bei der New Yorker Federal Reserve Bank (Fed) auf philippinische Konten. Dieser und weitere Fälle zeigen: Der Interbanken-Zahlungsverkehr ist ein lohnendes Angriffsziel. Und die Sicherheit des internationalen Finanznetzes SWIFT ist verletzlich. Der Aufwand, dort einzudringen, ist sicherlich groß, aber die zu erwartende Beute noch größer. Angesichts solch professioneller Attacken steht die Sicherheit des Zahlungsverkehrs erneut ganz oben auf der Agenda.


Die Bangladesh Bank wurde im Februar 2016 auf zwei Ebenen angegriffen. Offensichtlich waren die IT-Sicherheitseinrichtungen mangelhaft: Die Zentralbank verfügt angeblich über keine Firewall und nur über veraltete Netzwerktechnik. Durch diese Tür gelangten die Diebe in das Banknetz und dort an die Zugangsdaten für Überweisungen. Im SWIFT-Client Alliance Access konnten sie sich damit als Auftraggeber der Transaktionen autorisieren. Für die Fed traten die Urheber als Zentralbank von Bangladesch auf.

Die Sicherheitslücke erlaubte es den Angreifern laut BAE Systems auch, eine eigens programmierte Schadsoftware im SWIFT-Alliance-Server zu installieren. Diese Software manipulierte die Bestätigungsnachrichten des SWIFT-Netzes und schaltete den Zugriffsschutz für die Datenbank aus. Die ausgeführten Transaktionen wurden nicht korrekt protokolliert, um die Spuren zu verwischen.
Der Hacker-Angriff hebelte die Sicherheitsmechanismen von SWIFT komplett aus und eröffnete den Dieben nahezu unbegrenzte Möglichkeiten. Die Gesamtsumme der angeforderten Transaktionen belief sich gar auf 951 Millionen US-Dollar. Ein ungewöhnlicher Tippfehler in einer Nachricht ließ eine beteiligte Bank in Bangladesch nachfragen, ob die Überweisung so gewünscht sei. Nur dadurch fiel der gesamte Betrug überhaupt auf. Da waren die 81 Millionen aber bereits überwiesen und in philippinischen Kasinos und Privathänden verschwunden. In der Folge mussten Atjur Rahman, der Chef der Zentralbank Bangladesch, und seine Stellvertreter im März 2016 zurücktreten.

SWIFT selbst hat eingeräumt, dass in den letzten Monaten mehrfach betrügerische Nachrichten über das Netz gesendet worden sind. Im Mai 2016 war eine Geschäftsbank von einem ähnlichen Betrugsfall betroffen: Kriminelle sind in die IT-Systeme eingedrungen, haben Nutzerdaten abgegriffen und Nachrichten manipuliert. Nun sollen Updates die Sicherheitslücken in der SWIFT-Software schließen.

Auch wenn SWIFT betont, der Angriff stelle nicht die Sicherheit des Netzes infrage, sondern die des Zugangssystems, zeigt der Fall das Dilemma geschlossener internationaler Netze. Auch mit hohem technischem Aufwand lassen sie sich nicht absolut abschotten. Außer der Software des Netzbetreibers können auch die umgebenden Banksysteme eine Schwachstelle sein. Ganz zu schweigen von kriminellen Mitarbeitern, die beim Betrug mithelfen. Und sind die Angreifer erstmal drinnen, steht ihnen die ganze Welt offen. Das schafft Anreize. Ein Verfahren wie EBICS nutzt das offene Internet und verfolgt ein Sicherheitskonzept, das stark auf Schlüsseln für die Kryptografie und Authentifizierung basiert. Das kann eine Alternative zum geschlossenen Netz sein.

Angesichts der potenziell sehr großen Schäden muss der Interbanken- und Firmenkunden-Zahlungs­verkehr umfassend geschützt werden. Es ist zu erwarten, dass Cyber-Attacken wie die hier beschriebene zunehmen. Letztlich müssen die Sicherheitsmechanismen des Verfahrens, der Bank-IT und für das Personal lückenlos ineinander greifen.

Michael Lembcke 

Wie sich EBICS verbessern lässt, Teil 8 – Doppeleinreichungen mit EBICS-Mitteln verhindern: Was geht da?

Schnell ist es passiert. Die Zahlungsverkehrsaufträge wurden per EBICS versehentlich doppelt zur Bank übertragen. Keiner hat es bemerkt. Gleich mehrere solcher Fehlerfälle fallen einem da ein:
  1. In der Zahlungserfassung wird eine Zahlung doppelt erfasst und gesendet.
  2. Die Datei mit den Zahlungsaufträgen wird erneut und damit doppelt übertragen.
  3. Die Zahlungsdatei wird aus technischen Gründen doppelt übertragen, da der Übertragungsstatus des ersten Transfers unklar war.
Wesentlich für eine Doppeleinreichung ist, dass ein Kunde eine Zahlung bzw. Datei mit identischen Angaben in einem festgelegten Zeitraum erneut bei der Bank einreicht. Aber ist eine identische Einreichung stets eine generell abzulehnende Doppeleinreichung? Nein, denn manche Zahlungen werden vom Einreicher bewusst mehrfach ausgestellt und übertragen.


Wie also kann die Bankseite echte Doppeleinreichungen sicher erkennen und einen Schaden für den Kunden abwenden?

Es ist möglich, zumindest offensichtliche Doppeleinreichungen bereits bei der Einreichung im EBICS-Bankrechner zu erkennen und abzulehnen.

Im Fall der technischen Doppeleinreichungen (siehe 3.) erkennt das EBICS-Protokoll bis zur EBICS-Version 2.4, wenn ein Kunde eine vom EBICS-Client vergebene Order-ID in einem definierten Zeitraum erneut verwendet. Ab EBICS V2.5 vergibt der EBICS-Bankrechner bereits beim Aufbau der Kommunikation eine eindeutige Order-ID. Ein Doppeleffekt wie bei EBICS V2.4 kann somit nicht auftreten.

Der Fall, dass eine Datei oder ein Auftrag aber versehentlich mit einem neuen Transfervorgang und somit einer neuen Order-ID noch einmal gesendet wird (siehe 2.), kann mit den bestehenden EBICS-Mitteln auf dem EBICS-Bankrechner derzeit nicht ausgeschlossen werden. Um dafür eine effektive Doppeleinreichungsprüfung auf Dateiebene zu ermöglichen, soll mit der nächsten EBICS-Version der EBICS-CR EB-14-08 DoubleUploadControl umgesetzt werden.

Dieser CR verpflichtet den EBICS-Client, einen Hashwert über die Zahlungsdatei an den EBICS-Bankrechner zu übermitteln. Der Client erstellt diesen Hashwert ohnehin für die Signaturerzeugung. Der EBICS-Bankrechner muss prüfen, ob der Hashwert im betreffenden Zeitraum schon mal vorgekommen ist, und den Auftrag bei Doppeleinreichung ablehnen.

Eine weitergehende Doppeleinreichungsprüfung, z. B. auf Einzeltransaktionsebene (Fall 1.) ist schon komplizierter und muss nach wie vor außerhalb von EBICS gelöst werden. Ggf. muss ein Bankmitarbeiter in Rücksprache mit dem Kunden ermitteln, ob die doppelte Einreichung nicht doch gewollt ist.

Mit dem geplanten EBICS-CR EB-14-08 DoubleUploadControl wird EBICS um eine weitere sinnvolle Funktion ergänzt und verbessert. Dies ist auch erforderlich. Versehentliche Doppeleinreichungen können so frühzeitig verhindert werden. Allerdings kommt damit kein Allheilmittel. Die Bankanwendungen können auf weitergehende Doppelprüfungen nach wie vor nicht verzichten.

Michael Lembcke 

UBS goes EBICS

Patrik Giger, Head Payment Connectivity Services, UBS Switzerland AG

Bereits zum fünften Mal in Folge konnte UBS im Rahmen des von Euromoney durchgeführten Cash Management Surveys 2015 die Auszeichnung als "Best Domestic Cash Manager Switzerland" entgegennehmen. Dieser Erfolg beruht auf langjährigem Fokus auf Kundenbedürfnisse und optimaler Produkt- und Servicequalität.

Ein Bestandteil dieses Serviceangebots ist die Infrastruktur für die Direktanbindung von Kundensystemen. Hier hat sich über Jahre eine Schnittstelle bewährt, welche auf einem proprietären Datenaustausch basiert. Diese Direktanbindung wird von Kunden in der Schweiz genutzt. International nutzen Kunden vorwiegend eine Anbindung über SWIFT for Corporates oder Multibank-Angebote, um Zahlungsdaten und Reportings mit ihrem Finanzinstitut auszutauschen.

UBS-Kunden können bereits heute ihre globalen Finanzgeschäfte - vor allem auch für internationale Niederlassungen - sicher abwickeln. Ein grosses Ziel mit der neuen Infrastruktur ist, die Anbindung an Finanzinstitute noch sicherer, komfortabler und standardisierter zu gestalten.


Harmonisierung Zahlungsverkehr als Chance – und Herausforderung

Mit dem Gemeinschaftsvorhaben "Harmonisierung Zahlungsverkehr" haben sich die Schweizer Banken auf Plan geeinigt, bis im Jahre 2020 den Zahlungsverkehr in der Schweiz auf den internationalen ISO-20022-Standard zu heben (Details siehe http://www.paymentstandards.ch).
Konkret werden sich in den nächsten 4 Jahren bestehende Formate und Prozesse verändern, um Synergien in der Wertschöpfungskette zwischen Zahlungsverkehrsdienstleistern, Finanzinstituten und den Konsumenten nachhaltig ausschöpfen zu können. Diese Synergien werden schlussendlich zu Vorteilen für alle involvierten Akteure im Zahlungsverkehr führen. Der zu begehende Weg dahin ist nicht nur steil. Auch die Zeitvorgabe, um das Ziel zu erreichen, wurde sportlich berechnet. Was oft unterschätzt wird, sind die Auswirkungen, die diese Transformation auf Kunden haben wird. So wird die Formatveränderung mit grosser Sicherheit auch Veränderungen in den Prozessabläufen bei Firmenkunden nach sich ziehen.

Software-Partner als Drehscheibe der Harmonisierung

Die Informatikabteilung der Kunden sowie die IT-Berater respektive Software-Häuser spielen eine tragende Rolle bei der Migration des schweizerischen Zahlungsverkehrs. So verwenden über 90 Prozent der UBS-Kunden eine Standard-Software eines im Markt etablierten Herstellers für die Direktanbindung an ihre Banken. Kunden haben hier die klare Erwartung, dass die entsprechenden ERP (Enterprise Ressource Planning) respektive TMS (Treasury Management Software) Programme zeitgerecht und verlässlich mit den neuen ISO-Formaten umgehen können. Um den Software-Häusern den Weg zu den neuen ISO-20022-Formaten zu vereinfachen, stellt UBS eine dedizierte Testplattform zur Verfügung. Über diese können sowohl mittels manuellem Upload als auch über einen EBICS-Kanal Testdateien hochgeladen und validiert werden. Testergebnisse enthalten nebst den standardisierten Fehlercodes sehr detaillierte Informationen über allfällige Fehler oder suboptimale Nachrichtengestaltungen. Die Testplattform bietet Software-Anbietern auch einen "Readiness Test" an, welcher ihnen und ihren Kunden die ISO-20022-Fähigkeiten attestiert.

Bewährte proprietäre Lösung wird ersetzt

Bereits seit 2013 bietet UBS ihren Kunden EBICS als Kommunikationskanal an. Dieses Angebot wurde vereinzelt von Kunden mit sehr spezialisierter Finanz-Software gewählt. Die Mehrzahl der Kunden setzt nach wie vor die proprietäre Lösung ein. Dies ist vor allem darauf zurückzuführen, dass der Zahlungsverkehr in der Schweiz sehr stabil ist und sich über Jahrzehnte sehr wenig verändert hat. Es gab keinen Grund für Kunden, wie auch für lokale Software-Anbieter, die bestehenden und funktionierenden Lösungen im Bereich Zahlungsverkehr anzupassen. Das gleiche galt auch für Banken.

EBICS als idealer Kanal für ISO 20022

Weshalb nun zu den Formaten auch noch gleichzeitig die Kommunikationskanäle verändern? Analysen haben ergeben, dass der Aufwand sowohl auf Kunden- als auch auf Software-Partner- und Bankseite vergleichbar hoch ist, die neuen Formate im alten (proprietären) Kanal einzubauen, beziehungsweise die Bereitstellung über den neuen standardisierten EBICS-Kanal sicherzustellen. Führende Schweizer Finanzdienstleister bieten die Anbindung über EBICS bereits an oder sind in der Planung, diese Anbindung in naher Zukunft anzubieten.

Der Vorteil des EBICS-Standards liegt auf der Hand: Kunden werden davon profitieren, dass "Banken die gleiche Sprache sprechen". In der Schweiz haben wir zudem den Vorteil, dass wir auf bereits Bewährtes zählen können, denn EBICS hat sich in den letzten 10 Jahren, seit der Einführung in Deutschland, als stabiler und verlässlicher Kommunikationsstandard etabliert. Mit dem Beitritt der Schweiz als drittes Mitgliedsland in die EBICS-Gesellschaft (neben Deutschland und Frankreich) ist ein klares Signal gesetzt, dass die Schweizer Finanzdienstleister EBICS nicht als Nebenprodukt, sondern als strategischen Kommunikationskanal fördern.

Ringen um standardisierte Auftragsarten

Betreffend der Auftragsarten hat sich in der Schweiz der deutsche Ansatz durchgesetzt (Angabe des Inhaltes mit der Auftragsart), verglichen mit dem französischen Ansatz, der als Auftragsart lediglich "Upload" und "Download" kennt. Die Auftragsarten in der "Schweizer Empfehlung" werden weitestgehend harmonisiert. Durch die Migration des Zahlungsverkehrs besteht die grosse Chance, hier noch einen Schritt weiter zu gehen. So ist aktuell die Schweizer EBICS-Auftragsart "XE2" für Inlandüberweisungen sowie für SEPA- und für Auslandüberweisungen gültig. UBS setzt sich dafür ein, dass künftig die Auftragsarten ausgebaut werden, um den vollen Synergieeffekt von ISO 20022 und EBICS erzielen zu können. Konkret diskutiert man separate EBICS-Auftragsarten für Inlandzahlungen, Auslandzahlungen und SEPA-Zahlungen. Dieser Vorschlag wird innerhalb der relevanten Gremien intensiv diskutiert und UBS hofft, dass sich hier eine Standardisierung mit zusätzlichem Synergieeffekt erzielen lässt.

UBS goes EBICS – Globally!

UBS hat sich entschieden, die bestehende Kommunikations-Infrastruktur für den Massenzahlungsverkehr in der Schweiz mit einer standardisierten EBICS-Infrastruktur zu ersetzen. UBS geht noch einen Schritt weiter und plant EBICS auch als künftiges Protokoll für ihre Kunden in den globalen Buchungszentren sowohl in Europa als auch in Asien und den USA. Wichtig für diese Umsetzung ist, dass die Infrastruktur stabil und standardisiert ist. Durch die enge Zusammenarbeit mit der Firma PPI sind wir zusätzlich in der Lage, Kunden ohne EBICS-fähige Software künftig ein Plug-in zu empfehlen, welches für die Software des Kunden die Kommunikation übernimmt. Ausserdem wird zukünftig die Möglichkeit des EBICS-Portals "UBS KeyPort Web" als Alternative angeboten, wenn Kunden ihre Transaktionen als Dateien manuell über ein Internetportal hoch- beziehungsweise die Reporting Meldungen herunterladen wollen.

Das EBICS-Angebot von UBS richtet sich in erster Linie an Kunden, welche das Bedürfnis nach einer Direktanbindung an ihre ERP- und TMS-Systeme haben und in zweiter Linie an Kunden, welche ein "Multi-Booking-Center"-fähiges Portal für ihre Massenzahlungen benötigen. Für Individualtransaktionen und zusätzliche Informationen steht unseren Kunden nach wie vor das moderne und sehr vielseitige UBS e-banking zur Verfügung.

EBICS muss sich weiterentwickeln

UBS wird sowohl den deutschen (DK) als auch den französischen Standard unterstützen. Die Dringlichkeit einer weiteren Harmonisierung ist gegeben, denn schon mit drei Mitgliedern der EBICS-Gesellschaft ist die Vielzahl der unterschiedlichen Implementierungen hoch. Eine entsprechende weitere Harmonisierung wird von der EBICS-Gesellschaft unter dem Projektnamen BTF vorangetrieben (vgl. Artikel in diesem Blog von Sabine Wenzel, EBICS SCRL, http://www.ebicsblog.com/de/international-harmonisch-mit-ebics-btf/). Aus Sicht des Autors ist es essentiell, dass diese Harmonisierung mit sehr hoher Priorität vorangetrieben wird. Wir sind zuversichtlich, dass sich EBICS weiter global als Kommunikationsstandard ausbreiten wird. UBS ist hier an vorderster Front mit dabei und setzt auf EBICS in der Schweiz, in Deutschland, in Europa, in Asien und in den USA.

Patrik Giger

EBICS und TLS 1.2 – etwas sicherer, aber nicht ohne Tücken

Curd Reinert, Projektleiter EBICS-Kernel, PPI AG


Wer einen Blick in die aktuelle EBICS-Spezifikation wirft, stellt womöglich überrascht fest, dass dort für die Transport Layer Security (TLS) noch die Version 1.0 vorgeschrieben ist. Das war mal eine sehr kluge Wahl: Bei Veröffentlichung der EBICS-Spezifikation war TLS 1.0 der Stand der Technik. Man hat sich also vor allem gegen SSL entschieden. Und damit waren die Hersteller und Betreiber z. B. bei POODLE fein raus: EBICS schließt SSL aus, die EBICS-Anwendungen waren vor POODLE sicher. Ohnehin hätte POODLE bei einem EBICS-Client kaum eine Chance: Der Angreifer bringt den Client dazu, tausende Anfragen an den HTTPS-Server zu schicken, um z. B. an das Session-Cookie zu kommen. Bei EBICS wird aber weder ein Session-Cookie genutzt, noch sind die Clients Web-Anwendungen, die man per JavaScript dazu bringen kann, tausende Anfragen zu schicken. Aber erklären Sie das mal der Revision!


Und das war ja auch nur einer der bösen Angriffe mit den lustigen Namen: HEARTBLEED nutzte einen Fehler in der TLS-Implementierung von OpenSSL aus. Und dann ist da noch BEAST. Wie schon bei POODLE eignet sich EBICS auch nicht für den BEAST-Angriff. Aber der Ruf von TLS 1.0 ist nachhaltig beschädigt, und alle Seiten raten zum sicheren Nachfolger TLS 1.2.

Das hat man auch bei EBICS erkannt und entsprechende Change Requests für die nächste Version vorgesehen, um TLS 1.2 zu unterstützen. Leider verzögert sich diese nächste Version, und in der Zwischenzeit fragen die Revisoren: Wieso macht ihr mit EBICS noch TLS 1.0? „Weil es so in der Spezifikation steht“, reicht als Argument kaum noch aus, wenn das BSI offiziell vor dieser Version warnt. Auf der offiziellen EBICS-Seite stehen darum jetzt Sicherheitsempfehlungen, die zu TLS 1.2 raten – ohne zu erklären, wie sich das mit der Spezifikation vereinbaren lässt.

Wir haben 82 EBICS-Server in Deutschland und Frankreich getestet: Gerade einmal 52 Server konnten mit uns TLS 1.2 sprechen. Wenn Sie sich also als Kundenprodukthersteller heute dazu entschließen, TLS 1.0 gar nicht mehr zu unterstützen, dann können Sie sich mit ca. einem Drittel der EBICS-Server nicht mehr verbinden. Server-Betreibern dürfte es mit den Kundenprodukten in den unterschiedlichsten Versionen noch schlechter ergehen.



Was kann man dann tun? Man kann TLS 1.2 anbieten, ohne TLS 1.0 zu verbieten. Das geht sowohl als Client als auch als Server, und im TLS-Handshake einigen sich beide Seiten auf die sicherste gemeinsame Variante – so die Theorie. Bei immerhin 28 der getesteten Server hat das auch funktioniert. Leider haben wir aber auch zwei Server gefunden, die die Kommunikation rigoros abbrechen, wenn der Client TLS 1.2 vorschlägt. Das ist für die Hersteller von Kundenprodukten sehr unangenehm, weil die Clients dann nicht einfach „auf Verdacht“ TLS 1.2 vorschlagen können – oder sie nehmen in Kauf, dass die Kommunikation mit einigen wenigen Servern scheitert.

Wir haben die Betreiber der beiden EBICS-Server benachrichtigt. Da unser Test aber nicht alle EBICS-Server umfasst, sollte jeder Betreiber das Verhalten seines EBICS-Servers selbst prüfen.
Eine Frage drängt sich noch auf: Wie gefährlich wäre eine Entschlüsselung des TLS-Layers in EBICS überhaupt; welche Daten wären sichtbar? Die Auftragsdaten selber werden ein zweites Mal verschlüsselt und bleiben für den Angreifer unsichtbar. Es bleibt der XML-Rahmen um die Auftragsdaten, oder wie man es in der Post-Snowden-Ära nennt: Metadaten. Das sind vor allem die Auftragsart bzw. das Fileformat, die Kunden- und die Teilnehmer-ID. Mit anderen Worten: nicht besonders viel. Ob man damit die Gemüter beruhigen kann, steht auf einem ganz anderen Blatt.

Curd Reinert