Online-Banking, die Möglichkeit zur Abwicklung von Bankgeschäften über Online-Medien, gehört seit den Anfängen von kommerziellen Kommunikationsnetzen zu den meistgenutzten Anwendungen. Auch im Internet gehört Online-Banking deshalb zu den meistgenutzten Anwendungen.
Online-Banking als Prüfstein für Geschäftsbeziehungen über das Internet
Zweifellos gehören Bankgeschäfte zu den Geschäftsbeziehungen, bei denen Sicherheit und Authentizität oberstes Gebot sind. Bei Bankgeschäften, die elektronisch übertragen werden, also Kunde und Bankangestellter nicht direkt miteinander interagieren, ist deshalb ein hohes Maß an Sicherheit und Vertraulichkeit erforderlich, damit elektronisch übermittelte Aufträge genauso verbindlich behandelt werden können, wie direkt zur Bank getragene Aufträge.
Online-Banking hat seine Ursprünge in den Zeiten des Bildschirmtextes, damals noch unter dem Kontext Homebanking. Hier gehörte Homebanking tatsächlich zu den wichtigsten Killerapplikationen; das elektronische Führen des Girokontos war einer der Hauptargumente für die Nutzung von Bildschirmtext. Fast alle in Deutschland vertretene Banken boten deshalb schon frühzeitig Homebanking über Bildschirmtext an.
Aus dieser Zeit stammt auch das so genannte PIN/TAN-Verfahren, das sich deshalb schon jahrelang bewähren konnte, noch bevor das World Wide Web überhaupt entwickelt war:
Online-Banking mit PIN und TAN
Klassisches Online-Banking funktioniert mit einem Benutzernamen, einer persönlichen Identifikationsnummer (PIN), obwohl diese inzwischen nicht mehr nur eine Zahl sein muss, und einem Block von Transaktionsnummern (TAN), die von der Bank dem Kunden übergeben werden. Dieses Banking-Verfahren wird als PIN/TAN-Verfahren bezeichnet.
Mit dem Benutzernamen und der PIN, die der Kunde in einem ersten Brief von seiner Bank erhält, meldet sich der Kunde am Banking-System der Bank an. Nach dieser Anmeldung stehen ihm alle Geschäftsvorfälle zur Verfügung, die rein informativem Zweck dienen, also beispielsweise die Abfrage des Kontostands.
Für kontobewegende Geschäftsvorfälle ist zusätzlich eine TAN notwendig. Dazu erhält der Kunde von seiner Bank mit getrennter Post einen Block mit verschiedenen TAN (in der Regel 50 bis 100 Stück), die jeweils für einen kontobewegenden Geschäftsfall eingegeben werden muss. Ist eine TAN einmal erfolgreich für einen Geschäftsfall genutzt worden, ist sie verbraucht und kann nicht mehr verwendet werden. Der Kunde erhält, sobald seine TAN-Liste fast aufgebraucht ist, automatisch von seiner Bank eine neue TAN-Liste, die er mit einer TAN aus seiner alten Liste aktivieren muss.
Damit ist das PIN/TAN-Verfahren ein zweistufiges Banking-Verfahren: Der Benutzer authentifiziert sich beim Banking-System mit seinem Benutzernamen und seiner PIN, kontobewegende Aktivitäten autorisiert er zusätzlich mit einer TAN.
Dass das PIN/TAN-Verfahren aus einer Zeit vor dem Internet kommt, merkt man spätestens am Umstand, dass das Verfahren an sich kein Protokoll ist, sondern eben nur ein Verfahren. Es gibt keine einheitliche Spezifikation, beispielsweise über die Verschlüsselung der gesamten Kommunikation zwischen Kunde und Bank und über den Aufbau der Datenkommunikation. Dies war ursprünglich zu Zeiten des Bildschirmtexts auch nicht erforderlich, da hier jeder Kunde direkt mit dem Großrechner des Bildschirmtextsystems verbunden war, es also (theoretisch) keine Unklarheiten bezüglich des Anmeldenden gab und der Kunde direkt mit einer Schnittstelle seiner Bank kommunizieren konnte.
Eine weitere Problematik baut auf dieses Problem auf, denn wenn ein Unbefugter in den Besitz eines Benutzernamens, dessen PIN und einer TAN kommt, ist dieser in der Lage, eine Transaktion auszulösen. Eine regelrechte Szene nutzt das Phishing, das "Fischen" nach Zugangsdaten, für Betrügereien (siehe auch Phishing - Virtuelles Angeln nach Zugangsdaten). Diesen Betrügereien versuchen Banken mit verschiedenen Verfahren entgegenzutreten, die auf dem PIN/TAN-System aufsetzen:
- Indizierte TAN
Bei dieser Form von TAN-Listen erhält der Kunde ebenfalls eine gedruckte Liste mit 50 oder mehr TAN. Im Gegensatz zum normalen PIN/TAN-System wird bei der Aufforderung zur Eingabe einer TAN eine explizite TAN erfragt, beispielsweise die TAN Nummer 31. In so einem Fall muss der Benutzer auf seiner TAN-Liste die TAN Nummer 31 ablesen und zur Autorisierung eingeben. Mit diesem Verfahren wird es Betrügern schwerer gemacht, denn um zuverlässig das System aushöhlen zu können, müsste der Betrüger möglichst viele TAN und deren Position auf der TAN-Liste kennen. Dennoch ist auch dieses Verfahren - zumindest theoretisch - gefährdet, denn ein Betrüger könnte mit einem intelligenten System schon dann eine Verbindung zur Bank des Opfers aufbauen und bei der eigentlichen Abfrage der TAN diese vom Kunden im Dialog abfragen (in einer so genannten Man-in-the-middle-Attacke, siehe weiter unten). - Autorisierung mit externen Passwortgeneratoren
Externe
Passwortgeneratoren, oft auch als "Security Tokens" oder
nur "Tokens" bezeichnet, sind Passwortgeneratoren, die
entweder als eigenständiges Gerät, beispielsweise in
Form eines Taschenrechners (siehe Foto), oder als
kleines Softwareprogramm für PDA oder Mobiltelefone von
Banken zur Verfügung gestellt werden und TAN-Listen
ersetzen sollen. Zur Autorisierung einer Transaktion
wird dem Benutzer im Online-Banking-Vorgang eine Zahl
angezeigt, die er in seinen Passwortgenerator eingeben
und verarbeiten lassen muss. Der Passwortgenerator
liefert als Ergebnis wiederum eine Zahl, die der
Benutzer als TAN zur Autorisierung angeben muss. Im
Online-Banking-System wird ebenfalls die Zahl generiert
und mit der Zahl verglichen, die der Benutzer als
Ergebnis angegeben hat. Auch dieses Verfahren ist
ähnlich verwundbar, wie mit indizierte TAN-Listen und
einer Man-in-the-middle-Attacke, andererseits ist der
Benutzer mit einem externen Passwortgenerator flexibler,
da ihm die TAN nicht "ausgehen".
Stichwort: Man-in-the-middle-Attacke
Eine Man-in-the-middle-Attacke stellt eine recht aufwendig durchzuführendes Betrugsverfahren dar, das jedoch bei entsprechend professionell durchgeführter Abwicklung oft leider sehr wirkungsvoll ist. Grundsätzlich geht es dabei darum, dass ein Betrüger einen offiziellen Vorgang, beispielsweise die Zur-Verfügungstellung eines Online-Banking-Zuganges, nicht einfach nur simuliert (was bei Autorisierungsverfahren mit dynamischen Abfragen zwecklos wäre), sondern als Mittelsmann ("Man in the middle") sich aktiv zwischen dem Benutzer und dem Online-Banking-System stellt. Eine Man-in-the-middle-Attacke im Online-Banking könnte demnach folgendermaßen aussehen:
- Der Betrüger jubelt seinem Opfer eine Adresse unter, die auf eine fingierte Seite führt und dem Opfer vorgaukelt, ein offizieller Online-Banking-Zugang zu sein. Das Opfer fällt auf den Trick herein und stellt durch die Eingabe seiner Zugangsdaten diese dem Betrüger zur Verfügung.
- Der Betrüger erhält diese Zugangsdaten und baut zeitgleich mit diesen Daten seinerseits eine Verbindung zum echten Online-Banking-System auf. Ist diese Anmeldung erfolgreich, meldet der Betrüger dem Opfer, dass die Anmeldung am Online-Banking-System derzeit noch durchgeführt wird, um Zeit zu gewinnen.
- Der Betrüger startet am echten Online-Banking-System umgehend einen Überweisungsvorgang und wird dort im letzten Schritt aufgefordert, eine bestimmte TAN zur Autorisierung anzugeben.
- Der Betrüger meldet dem Opfer zurück, dass seine Anmeldung angeblich nun erfolgreich gewesen sei und fordert ihn auf, eine bestimmte TAN (nämlich genau die, die er im vorherigen Schritt angeben muss) zur Autorisierung einzugeben.
- Das Opfer gibt die entsprechende TAN durch, der Betrüger empfängt diese, gibt sie unmittelbar im Rahmen des laufenden Überweisungsvorganges ein und autorisiert auf diese Weise erfolgreich die Überweisung.
Es leuchtet ein, dass gerade das PIN/TAN-System sehr anfällig für eine Man-in-the-middle-Attacke ist, da die zu übergebende, geheime Information zur Autorisierung (die TAN) eine einfache Zahlenkombination ist. Indizierte TAN oder externe Passwortgeneratoren stellen lediglich die Meßlatte für Gauner höher, lösen jedoch keinesfalls das grundsätzliche Problem zuverlässig.
Online-Banking mit HBCI
HBCI steht für Home Banking Computer Interface (Homebanking Computerschnittstelle), einem deutschen Standard, der vom Bundesverband deutscher Banken e.V., dem Bundesverband der Volks- und Raiffeisenbanken e.V., dem Deutschen Sparkassen- und Giroverband e.V. und dem Bundesverband öffentlicher Banken e.V. im so genannten HBCI-Abkommen unterzeichnet wurde. Nach diesem Abkommen haben sich alle an den Verbänden angeschlossenen Kreditinstitute verpflichtet, HBCI als Homebanking-Standard im Jahr 1997 einzuführen. HBCI besitzt eine einheitliche Definition für viele Arten von Geschäftsfällen und stellt damit einen grundsätzlichen Ansatz, das Online-Banking zu vereinheitlichen.
Geschäftsvorfälle werden in HBCI in so genannten HBCI-Nachrichten übertragen. Diese bestehen aus folgenden Bestandteilen, die ineinander gekapselt werden, wobei der Nachrichtenkopf mit dem Nachrichtenabschluss die äußerste Kapselung bilden:
- Nachrichtenkopf
Der Nachrichtenkopf leitet eine HBCI-Nachricht ein und enthält neben administrativen Informationen unter anderem eine Nachrichtennummer, die am Ende der HBCI-Nachricht im Nachrichtenabschluss nochmals auftaucht. - Chiffrierkopf
Der Chiffrierkopf ist eine optionale Schicht, die in einer HBCI-Nachricht verwendet wird, wenn Kundendaten übertragen werden. Werden beispielsweise über eine HBCI-Nachricht allgemeine Werbeangebote des Kontoinstituts übertragen, wird für gewöhnlich keine Verschlüsselung benötigt und deshalb auch kein Chiffrierkopf eingefügt. - Signaturkopf
Der Signaturkopf enthält Daten über die Sicherheitsverfahren, die anzuwenden sind und zusätzliche Daten, die sicherstellen, dass die HBCI-Nachricht eindeutig gekennzeichnet ist und beispielsweise Doppelausführungen vermieden werden. Der Signaturabschluss enthält zusätzlich eine digitale Signatur. - Segmentkopf
Der Segmentkopf leitet schließlich den Bereich ein, der die eigentlichen HBCI-Nutzdaten, also auch Geschäftsvorfälle, enthält. Hier können durchaus auch mehrere Geschäftsvorfälle gleichzeitig in einer HBCI-Nachricht transportiert werden.
Die Verschlüsselung erfolgt, wie bereits kurz erwähnt, auf Basis von digitalen Signaturen mit asymmetrischen Verschlüsselungsverfahren. Hierbei besitzen sowohl das Bankinstitut, als auch der Bankkunde jeweils ein Schlüsselpaar, bestehend aus einem so genannten privaten und einen öffentlichen Schlüssel, die beide mathematisch zusammenhängen. (Zur näheren Beschreibung des so genannten Public-Key-Verfahrens sei das Dokument über Verschlüsselungsverfahren empfohlen). Der öffentliche Schlüssel eines Schlüsselrings dient zur Verschlüsselung von Daten, die nur mit dem dazugehörigen privaten Schlüssel, der immer beim Kunden verbleibt, wieder entschlüsselt werden können.
Um per HBCI Online-Banking zu nutzen, erhält der Bankkunde von seinem Bankinstitut sein Schlüsselpaar entweder auf einer Chipkarte oder übergangsweise auf einer Diskette. Mit diesem Schlüsselpaar muss der Bankkunde nun zunächst die Initialisierung vornehmen, bei der das Online-Banking-System des Bankinstitutes Kenntnis über das Schlüsselpaar des Kunden erhält und die Authentizität sichert.
Bei dieser Initialisierung baut der Bankkunde eine Verbindung zum Online-Banking-System auf und erhält als erstes den öffentlichen Schlüssel des Bankinstitutes. Dieser Schlüssel enthält einen so genannten Hash-Wert, vergleichbar mit einem Fingerabdruck. Diesen Hash-Wert vergleicht er mit dem Ausdruck des öffentlichen Schlüssels, den das Bankinstitut dem Bankkunden auf dem Postweg oder persönlich überreicht hat. Ist dieser Hash-Wert in beiden Fällen gleich, kann der Kunde davon ausgehen, tatsächlich mit seinem Bankinstitut zu kommunizieren.
Die gleiche Prozedur erfolgt nun danach auch auf der anderen Seite. Das Bankinstitut erhält elektronisch den öffentlichen Schlüssel des Bankkunden und legt diesen vorläufig zur Prüfung zurück. Der Bankkunde muss nach dieser Übertragung seinen öffentlichen Schlüssel in den so genannten Ini-Brief ausdrucken, diesen handschriftlich unterschreiben und zum Bankinstitut schicken. Das Bankinstitut vergleicht dann den Hash-Wert des übermittelten, öffentlichen Schlüssel des Bankkunden mit diesem Ini-Brief und gibt, falls die Hash-Werte übereinstimmen, den Kunden für das Online-Banking frei.
Die Vorteile von HBCI gegenüber dem klassischen PIN/TAN-Verfahren sind bestechend: Zum einen handelt es sich bei HBCI um ein vollständiges Banking-System, bei dem Verschlüsselung und alle gängigen Geschäftsvorfälle normiert sind und deshalb beispielsweise auch Banking-Software einheitlich genutzt werden kann, ohne dass für jedes Bankinstitut eigene Anpassungen erforderlich wären. Weiterhin besitzt HBCI durch die asymmetrische Verschlüsselung eine Möglichkeit zur sicheren Authentifizierung des Bankkunden, weshalb keine zusätzliche TAN-Liste zur Autorisierung von kontobewegenden Geschäftsvorfällen notwendig ist. Und letztendlich ist das HBCI-Verfahren für Betrüger weitgehend uninteressant und auch gegen Man-in-the-middle-Attacken weitgehend immun, da der Betrüger zwingend im Besitz der Chipkarte des Benutzers sein muss, da diese die Schlüssel des Benutzers enthält und auch die Ver- bzw. Entschlüsselungsoperationen direkt vornimmt, die von der Banking-Software während den Banking-Prozessen an die eingesteckte Chipkarte geliefert werden. Die Schlüssel des Benutzers können demnach niemals aus der Chipkarte ausgelesen werden, ohne die Karte selbst zu zerstören. Und nicht zuletzt ist durch HBCI auch die Entwicklung von plattform- und institutsunabhängiger Banking-Software möglich. So ein Projekt ist beispielsweise das Projekt hbci4java.
Nachteilig bei HBCI ist die initiale Anfangsprozedur mit dem Ini-Brief, die im Gegensatz zum PIN/TAN-Verfahren erheblich komplexer ist. Entsprechende Abläufe in Banken könnten jedoch dafür sorgen, dass beispielsweise die Erzeugung des Ini-Briefes und das Unterzeichnen desselbigen bereits in der Bankfiliale an einem gesonderten Rechner erfolgt, so dass der Benutzer mit dieser Aufgabe nicht alleine gelassen wird.
Mogelpackung HBCI+
Trotz dem Internet-Boom blieben viele Banken beim Thema Online-Banking jahrelang eher konservativ. Während größere Banken und Bankverbünde schon recht bald auch das Internet als Zugangsweg zu Bankgeschäften nutzten, blieben viele Banken in Deutschland zunächst skeptisch und blieben weiterhin beim Homebanking über BTX, inzwischen im Jahre 1995 umgetauft in Datex-J ("Jedermann") und eingebracht in T-Online, dem Online-Dienst der Deutschen Telekom.
So begann eine jahrelange Zeit des friedlichen, aber unsinnigen Nebeneinanders zwischen dem immer stärker verbreiteten Online-Banking über das Internet und dem veralteten Homebanking über dem CEPT-basierten Homebanking, das einzig und allein nur über T-Online funktionierte. Zwar stellten immer mehr Banken ihr Homebanking um und animierten ihre Kundschaft, auf das Online-Banking im Internet zu wechseln, dennoch nutzten auch weiterhin viele Firmen den Datenaustausch mit ihrer Bank über CEPT bzw. über T-Online.
Dem setzte T-Online Ende 2001 ein Ende und stellte den direkten CEPT-Zugang ein und implementierte in den T-Online-Decoder ein CEPT-Gateway, um für alte Software eine adäquate Alternative zu schaffen. Gleichzeitig erhöhte T-Online die Gebühren für die Banken, um über den Geldhahn einen längst fälligen Zeitenwechsel einzuleiten und sich einer völlig veralteten Technik endgültig zu entledigen. Da nun plötzlich dringend eine bankenübergreifende Alternative benötigt wurde, die jedoch möglichst auf dem PIN/TAN-Verfahren aufsetzen sollte, entwickelte der Zentrale Kreditausschuss im Rahmen von HBCI das Verfahren HBCI+, oft auch HBCI-PIN/TAN-Verfahren genannt.
War HBCI bis dato ein fortschrittlicher Standard auf Basis einer zertifikatsbasierten Authentifizierung und Verschlüsselung, ist HBCI+ an sich ein glatter Rückschritt: Die Authentifizierung des Kunden erfolgt allein über die PIN des Kunden und die Autorisierung eines Zahlungsvorganges über eine TAN. Die Verschlüsselung des gesamten Banking-Vorganges erfolgt über die altbekannte SSL-Verschlüsselung.
Dadurch ist HBCI+ nicht unbedingt unsicherer, als das "echte" HBCI, dennoch ist es ein Wolf im Schafspelz. Es werden, vermutlich aus Kostengründen, nicht die Möglichkeiten und Vorteile ausgenutzt, die HBCI eigentlich von Hause aus bereits mitbringt: Eine erheblich bessere Authentifizierung des Benutzers und vor allem die Abkehr der eher lästigen TAN-Listen.
Die Zukunft und viele kleine proprietäre Trippelschritte
Der Zentrale Kreditausschuss, ein Zusammenschluss aus den fünf Spitzenverbänden der deutschen Kreditwirtschaft (Bundesverband der Deutschen Volksbanken und Raiffeisenbanken e.V., Bundesverband deutscher Banken e.V., Bundesverband Öffentlicher Banken Deutschlands e.V., Deutscher Sparkassen- und Giroverband e.V. und Verband deutscher Pfandbriefbanken e.V.), erkannte nach der Veröffentlichung von HBCI 2.2 das Problem, dass HBCI zwar ein sicheres, dennoch aber weiterhin kompliziertes System ist und dass sich das Kundenverhalten im Laufe der Zeit wiederum verändert hatte; das PIN/TAN-Verfahren zeigte sich weiterhin als ein für den Kunden attraktives System. Freilich kommt noch hinzu, dass der Begriff "HBCI" in der Zwischenzeit ein schweres Erbe geworden war, da viele Bankinstitute erhebliche Gelder in die Anschaffung von HBCI-fähigen Banking-Anwendungen gesteckt hatten und dennoch nur die wenigsten Kunden von den Vorteilen überzeugen konnten. Ganz zu schweigen vom Umstand, dass HBCI auch nach Jahren eine immer noch weitgehend deutsche Angelegenheit geblieben ist und sich nie international durchsetzen konnte.
Der ZKA stellte deshalb im Jahre 2002 einen neuen Standart namens FinTS (Financial Transaction Services) vor. FinTS beinhaltete nun von vorneherein sowohl zertifikatsbasiertes, als auch PIN/TAN-basiertes Banking in einem einheitlichen Transaktionssystem, um beide Systeme voll zu unterstützen. Tatsächlich ist das zertifikatsbasierte Banking in FinTS weitgehend der bisherige HBCI-Standard, während nun aber in FinTS ein einheitliches Rahmenwerk auch für das PIN/TAN-Verfahren integriert wurde. In einer zweiten Fassung wurde die FinTS-Kommunikation gänzlich auf XML (siehe zum Thema XML auch XML - Extensible Markup Language) umgestellt, so dass FinTS nun eigentlich ein wirklich "erwachsen" gewordenes Rahmenwerk für Online-Banking geworden ist, das für praktisch alle Geschäftsvorfälle einer Bank, die elektronisch abgewickelt werden können, vorbereitet ist.
Dennoch scheint FinTS zunächst wiederum eine ähnliche Odyssee zu erleiden, wie damals HBCI. Zwar unterstützen viele Bankinstitute offiziell FinTS, bisher bieten jedoch nur die wenigsten Banken FinTS direkt ihren Kunden an. Ebenfalls mangelhaft ist die FinTS-Unterstützung der meisten Banking-Programmen - sie ist schlicht in den meisten Programmen nicht implementiert. Die Auswirkungen dieser schleppenden Unterstützung sind gravierend: Die meisten Banken setzen weiterhin auf proprietäre und untereinander inkompatible Banking-Anwendungen für ihr Online-Banking. Dies bedeutet beispielsweise, dass die meisten Zugänge zum Online-Banking nur über Web-Seiten zugänglich sind und ein Kunde von mehreren Banken mühsam jede einzelne Bank online "abklappern" muss und er umständlich Daten im- und exportieren muss, wenn er seine Buchhaltung in einem externen Programm führt - wenn seine Bank das Im- und Exportieren von Geschäftsvorfällen überhaupt in ihrer Anwendung unterstützt.
Weiterführende Links
http://www.hbci-zka.de/
Offizielle Homepage des Zentralen Kreditausschusses zu HBCI und FinTS
http://www.zahlungsverkehrsfragen.de/
Private Website zu Zahlungsverkehrsfragen, unter anderem
auch Online-Banking
http://ancoso-development.de/Produkte/hbci/
hbci4java-Projekt
