| 
Haben Sie einen Fehler gefunden? Bitte benachrichtigen Sie uns per E-Mail. Vielen Dank.
Electronic Banking ist heute für viele Privat- und Firmenkunden unverzichtbar. Während die meisten Privatleute nur ein einziges Konto unterhalten, müssen Unternehmen oft mit mehreren Banken elektronisch kommunizieren und haben ein erhöhtes Transaktionsaufkommen. 1995 wurde zur Datenübertragung zwischen Bank und Kunde unter dem Kürzel FTAM ein Standard für "File Transfer, Access and Management" eingeführt. Mit dem FTAM-Protokoll kann jedes inländische Unternehmen jedes Kreditinstitut in Deutschland erreichen.
FTAM war lange Zeit der einzige Multibank-Standard für das E-Banking im Firmenkundengeschäft. 2006 hat der Zentrale Kreditausschuss (ZKA) nachgerüstet und mit dem Electronic Banking Internet Communication Standard (EBICS) einen modernen Nachfolger auf Internetbasis geschaffen: EBICS verspricht höhere Sicherheit bei gleichzeitiger Kostenreduktion und Prozessbeschleunigung durch IP-Zugriff. Ein ZKA-Abkommen verpflichtet alle Banken dazu, ab dem 1. Januar 2008 das EBICS-Verfahren zu unterstützen und das derzeitige Protokoll FTAM nach und nach abzulösen – die bankseitige Verpflichtung zur Unterstützung des bisherigen FTAM-Standards erlischt jedoch erst zum 31. Dezember 2010.
Das etablierte FTAM-Verfahren nutzen in erster Linie Firmenkunden mit hohem Zahlungsverkehrsaufkommen im Inland. Für Sicherheit sorgt eine elektronische Unterschrift (im FTAM-Umfeld oft "EU" abgekürzt – im Folgenden kurz als Signatur bezeichnet). Eine Kontrolle der Transaktionen erfolgt durch das Abrufen von Status-Protokollen.
Die Verbindung zwischen dem Kunden- und dem Bankrechner erfolgt über ISDN; somit ist als technische Voraussetzung für das FTAM-Verfahren lediglich ein Standard-PC mit ISDN-Zugang über das Common-ISDN-Application-Programming-Interface (CAPI) nebst Installation eines FTAM-fähigen Zahlungsverkehrsprogramms notwendig. Die Freischaltung für das FTAM-Verfahren erfolgt mit den entsprechenden Vereinbarungen durch das Kreditinstitut.
Über eine FTAM/ISDN-Verbindung lassen sich durchaus ansehnliche Datenmengen übertragen; die dedizierten ISDN-Verbindungen verursachen allerdings relativ hohe Übertragungskosten. Der Einsatz eines Public-Key-Verfahrens zur Erstellung von elektronischen Unterschriften verspricht hohe Sicherheit, die Notwendigkeit nur einer Signatur für alle Banken sorgt für Komfort. Über die Verabredung, dass zwei Unterschriften für eine Transaktions-Freigabe nötig sind, kann ein Vier-Augen-Prinzip zur erhöhten Sicherheit beitragen. Außerdem können verschiedene Berechtigungs-Level für mehrere Benutzer eingerichtet werden.
Mit EBICS hat die deutsche Kreditwirtschaft die Forderung von Kunden und Instituten nach einer internetbasierten Lösung im Electronic Banking erfüllt. Ziel dieser Erweiterung ist es, den einheitlichen und multibankfähigen Standard FTAM für Übertragungsmöglichkeiten im Internet auszubauen und die damit verbundenen Anwendungsmöglichkeiten zu erweitern.
Das EBICS-Protokoll sieht standardmäßig eine doppelte Verschlüsselung von Daten sowohl auf Transportebene (TLS/SSL) als auch in der Ende-zu-Ende-Kommunikation vor. Außerdem wird jede Transaktion mittels digitaler Signatur unterschrieben, sei es zur Autorisierung (bankfachliche elektronische Unterschrift) oder zum Einreichen eines Auftrags (Transport-Unterschrift). Auch die Anmeldung und Authentifizierung am Banksystem erfolgt nicht mehr wie beim FTAM-Verfahren durch die Verifizierung eines Passworts, sondern ebenfalls durch eine digitale Signatur (Authentifizierungssignatur). Die digitalen Signaturen zur Autorisierung von Transaktionen können auch nach dem Einreichen eines Auftrages standort- und zeitunabhängig mittels einer verteilten elektronischen Unterschrift (VEU) erfolgen.
----------Anfang Textkasten----------
Das EBICS-Protokoll sieht für jeden Teilnehmer drei RSA-Schlüsselpaare mit den folgenden Verwendungszwecken vor:
----------Ende Textkasten----------
Gleichzeitig ermöglicht die Internetbasis breitbandige Verbindungen mit höheren Datenübertragungsvolumen zu geringeren Kosten. Anders als FTAM setzt EBICS nicht auf proprietäre Protokolle, sondern auf internationale Kommunikations- und Sicherheits-Standards, unter anderem TLS/SSL und XML. Durch die Nutzung von HTTPS sind in der Regel keine gesonderten Firewall-Regeln notwendig, sofern der Standard-Port 443 nutzbar ist. Per Transport Layer Security (TLS) werden sowohl der angesprochene Server authentifiziert als auch der Übertragungskanal chiffriert.
EBICS behandelt bankfachliche Nutzdaten transparent: Die Auftragsdaten werden unabhängig von der spezifischen Datenstruktur unterschiedlicher Auftragsarten als binärer Block behandelt und in eine XML-Struktur eingebettet – vor dem Versand erfolgen stets zuerst eine ZIP-Kompression, dann Verschlüsselung (auf Applikationsebene) und Base64-Kodierung. Die Auftragsdatenverschlüsselung erfolgt dabei hybrid, also symmetrisch für die eigentlichen Daten und asymmetrisch (Public Key) für den verwendeten Transaktionsschlüssel.
Die Verschlüsselung der Auftragsdaten zusätzlich zur TLS-Transportsicherung gewährleistet, dass Informationen sowohl auf dem Weg über öffentliche Netze als auch jenseits der TLS-geschützten Verbindungsstrecke vor unautorisiertem Lesezugriff geschützt bleiben. Darüber hinaus kommen verschiedene ZKA-Standards zur Verschlüsselung und Signatur zum Einsatz (z. B. A004, E001 und X001).
| Thema | "DFÜ mit Kunden" | EBICS |
|---|---|---|
| Multibankfähigkeit | ja | ja |
| Kommunikationsweg | FTAM-Filetransfer, OSI-Standard über X.25 oder ISDN | HTTP(S), TCP/IP, IP-Netze (insbesondere Internet, aber auch LAN möglich) |
| Sicherheit |
|
Verbesserungen bzgl. Sicherheit durch mehr Signaturen als bisher:
|
| Infrastruktur / Kosten | Kosten für ISDN (Support, Hardware) | (bestehenden) Internetanschluss nutzen, Kosten providerabhängig |
| Bandbreite der Übertragung / Datenvolumen | max. 64 kbps bei ISDN (ohne Kanalbündelung) | kann beliebig erhöht werden, schnelle Internetverbindungen können genutzt werden, ZIP-Komprimierung ist Pflicht (verringert Datenvolumen, erhöht somit Geschwindigkeit) |
| Datenmodell | Kunde, Teilnehmer, Konto | analog zum "DFÜ mit Kunden" mit erweiterten Attributen z. B. für die verteilte elektronische Unterschrift (EVU) |
| Produkte | im Wesentlichen Offline-Produkte | Da keine Architekturvorgaben am Kundensystem festgelegt sind, gibt es eine größere Bandbreite möglicher Kundenprodukte, u. a. Internet-Clients und Java-Applets. |
| Anmeldung | FTAM-Passwort | wird ersetzt durch die Authentifizierungssignatur – abhängig von der Ausgestaltung des Kundensystems muss dies jedoch nicht unbedingt für den Kunden erkennbar sein (ggf. also gleiche Handhabe wie bisher) – zudem noch TLS-/SSL-Server-Authentifizierung (automatisch im Hintergrund) |
| Erfassung der Auftragsdaten | Die Daten für die Bildung von Formaten wie DTAUS und DTAZV müssen erfasst werden. | wie bisher – es werden die gleichen Formate erstellt |
| Senden von Dateien
= Kunde an Bank |
über Auftragsarten | wie bisher – jedoch muss jede gesendete Datei unterschrieben werden: entweder bankfachlich durch die elektronische Unterschrift (Autorisierung) oder reiner Transport (Transportunterschrift) Steuerung durch neue Unterschriftsklassen: Jeder Teilnehmer hat eine bestimmte Unterschriftsklasse, neu ist die Klasse für den reinen Transport ("T"). |
| Abholen von Dateien
= Bank an Kunden |
über Auftragsarten | wie bisher – außerdem ist geplant, eine optionaleUnterschrift der Bank in einem späteren Release einzuführen (z. B. im Rahmen des elektronischen Kontoauszugs) |
| Elektronische Unterschrift | kryptografische Verfahren gemäß DFÜ-Abkommen (RSA-Verfahren) | wie bisher – jedoch aufsetzend bei A004, ältere Unterschriftsversionen werden nicht unterstützt. |
| Verschlüsselung | optionale Verschlüsselung der Auftragsdaten über ZKA-Verschlüsselung | ZKA-Verschlüsselung der Auftragsdaten ist Pflicht; zudem verpflichtende Verschlüsselung des gesamten Datenstroms (inklusive der Steuerdaten) mit TLS/SSL |
| INI-Brief | Erstinitialisierung des Teilnehmers beim Banksystem | wie bisher |
| Anwendungsprotokoll | FTAM-proprietär | XML-Schnittstelle |
| Speichermedium für Legitimationsdaten (= Unterschrift) | Standard schreibt nichts vor – gängig sind Chipkarte bzw. USB-Stick oder Diskette | wie bisher |
Vergleich zwischen FTAM und EBICS (Tabelle als Grafikdatei).
Um bankfachliche EBICS-Transaktionen mit einem bestimmten Kreditinstitut durchführen zu können, muss natürlich zunächst ein entsprechender Vertrag zwischen Kunde und Bank geschlossen werden; anschließend erhält der Kunde Client-Software und Zugangsdaten. Zu den weiteren administrativen Voraussetzungen gehören die erfolgreiche Teilnehmerinitialisierung und das Abholen der öffentlichen Schlüssel des Kreditinstituts durch den Teilnehmer.
Zu den technischen Anforderungen an den EBICS-Client gehören konkrete Anforderungen an das Schlüsselmanagement: Die geheimen Teilnehmerschlüssel müssen gegen unautorisiertes Auslesen und Verändern geschützt sein, beispielsweise auf Smartcards. Die genauen Richtlinien für die sichere Schlüssel-Speicherung sind jedoch Bestandteil der Kundenbedingungen der Kreditinstitute.
Des Weiteren gilt es die Kundensoftware gegen Manipulationen zu sichern, damit Teilnehmer nicht über den Ablauf von EBICS-Transaktionen getäuscht werden können. Zu betonen ist hierbei, dass der Schutz der Client-Software und der internen Kommunikationswege allein in der Verantwortung der Kunden liegt und kundenindividuell zu lösen ist.
----------Anfang Textkasten----------
Für die Implementierung des EBICS-Standards werden die nachfolgend aufgeführten Basiskomponenten benötigt, die üblicherweise in der überlassenen Client-Software enthalten sind. Lösungen für diese Komponenten sind unter anderem auch in Java verfügbar.
----------Ende Textkasten----------
Die enthaltene elektronische Unterschrift stellt bei EBICS die Authentizität des Absenders sowie der Auftragsdaten sicher – jenseits der TLS-Übertragungsstrecke und unabhängig von der Kompression, Verschlüsselung, Kodierung sowie Segmentierung der Auftragsdaten. Sie dient entweder zur Autorisierung der Einreichung (Transportunterschrift) oder des Auftrags selbst (bankfachliche elektr. Unt.). Letztere kann auch verteilt, also separat nach Einlieferung der Auftragsdaten, und standortunabhängig mittels verteilter elektronischer Unterschrift (VEU) erfolgen.
Unabhängig von den autorisierenden Unterschriften wird die Authentizität von Kunden- und Banksystem in jedem Datenpaket einer Transaktion durch Signaturen sichergestellt, um unautorisierte Zustandsänderungen von Aufträgen oder Daten durch Unberechtigte zu unterbinden. Diese Authentifizierungssignatur wird gemäß dem XML-Signature-Standard erzeugt und sowohl über die Steuerdaten als auch die enthaltene elektronische Unterschrift gebildet.
Die Authentifizierungssignatur jeder EBICS-Nachricht muss vom jeweiligen Empfänger überprüft werden. Bei fehlerhafter Verifikation einer Signatur, kann das Banksystem nicht davon ausgehen, dass der zugehörige EBICS-Request tatsächlich vom vorgeblichen Teilnehmer stammt. Kann umgekehrt die Authentifizierungssignatur einer EBICS-Response nicht erfolgreich überprüft werden, so kann das Kundensystem nicht davon ausgehen, dass diese Antwort vom erwarteten Banksystem stammt – in diesem Fall ist die betroffene Transaktion abzubrechen.
Alle Transaktions-Einreichungen müssen signiert erfolgen – selbst wenn der einreichende Mitarbeiter nicht zur Autorisierung von Aufträgen selbst berechtigt ist. Jeder Teilnehmer erhält hierzu vom Kreditinstitut eine Berechtigung für seine elektronischen Unterschriften zugewiesen: Beispielsweise haben Teilnehmer mit der Unterschriftsklasse "A" die Berechtigung zur Erstunterschrift von Aufträgen, Berechtigungen des Typs "T", zu denen die Transportunterschrift gehört, werden den Teilnehmern pauschal oder in Kombination mit bestimmten Auftragsarten zugewiesen – sie sind jedoch nicht abhängig von Konten oder Betragslimits.
Die verteilte elektronische Unterschrift (VEU) dient wie angesprochen der standortunabhängigen Information und Autorisierung und ermöglicht es, Aufträge orts- und zeitunabhängig von mehreren Teilnehmern – auch kundenübergreifend – autorisieren zu lassen. Ein Unterschriftsberechtigter kann sich per VEU beispielsweise allerorts über durch die Buchhaltung eingereichte Zahlungsaufträge detailliert informieren lassen und diese dann auch nachträglich autorisieren. Die bankseitige Unterstützung für die verteilte elektronische Unterschrift ist verbindlich für jedes Kreditinstitut.
Ein noch nicht abschließend autorisierter Auftrag bleibt in der VEU-Prozessverarbeitung hierzu zunächst als unerledigt gespeichert: Informationen über Aufträge, die sich in dieser Prozessverarbeitung befinden, können durch so genannte Download-Transaktionen abgerufen werden. Anschließend können dem Auftrag zusätzliche elektronische Unterschriften zugeteilt werden. Sobald die geforderte Anzahl geleisteter Signaturen mit den passenden Berechtigungen für die vorliegende Auftragsart erreicht ist, wird der Originalauftrag aus der VEU-Prozessverarbeitung freigegeben und gelangt in die weitere Auftragsverarbeitung.
Die Migration zu EBICS lohnt sich: Derselbe Standard gilt für alle Kreditinstitute; Firmenkunden erreichen also mit nur einer Software jede Bank oder Sparkasse. Die Ausgestaltung als offener Standard ermöglicht den Firmenkunden, entweder Standard-Produkte oder individuelle Software einzusetzen. Das moderne Verfahren und internationale Standards sorgen für höchste Sicherheit, unter anderem durch die mehrfache Verschlüsselung auf Transportebene und in der Ende-zu-Ende-Kommunikation.
EBICS ist ein Transportmittel für alle Geschäftsprozesse: Lastschriften, Überweisungen, Kontoauszüge, Cash-Management, Wertpapierorders und vieles mehr lassen sich damit internetbasiert abwickeln. Durch ein mehrstufiges Unterschriftskonzept ist die Einbeziehung von Dienstleistern möglich, die VEU ermöglicht eine standortunabhängige Freigabe von Aufträgen.
Dr. Rüdiger Mock-Hecker ist Leiter der Geschäftssparte Kartensysteme des DSV und Vorstandsvorsitzender des Berufsverbands deutscher Trust-Center-Betreiber und Zertifizierungsanbieter T7 e. V.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007#6, Seite 63
tag:kes.info,2007:art:2007-6-063
|