HBCI steht für Homebanking Computer Interface und ist ein vom deutschen Zentralen Kreditausschuss standarisiertes Protokoll für Online-Banking, d.h. für die Erledigung von Bankgeschäften über das Internet.
Mit der Version 3.0 im Jahre 2002 wurde HBCI umbenannt in FinTS (Financial Transaction Services), siehe unten.
Inhalt
Inhaltsverzeichnis
1. Technische Merkmale
Das herausragende Merkmal von HBCI ist die Bankenunabhängigkeit und die öffentliche Verfügbarkeit der Standarisierungs-Dokumente. Dadurch ist es prinzipiell jedem Programmierer oder Softwarehersteller möglich, eine Implementierung der Client-Seite von HBCI zu erstellen und damit auf alle HBCI-fähigen Banken zuzugreifen. Der Standard sieht dazu mehrere Möglichkeiten der wirkungsvollen Authentifikation vor, so daß diese Hersteller- und Bankenunabhängigkeit in der Praxis tatsächlich für echte Geldgeschäfte in Anspruch genommen werden kann.
1.1. Geschichte
HBCI wurde in brauchbarer Form erstmals im Jahre 1998 als Version 2.01 veröffentlicht; Entwürfe reichen bis ins Jahr 1995 zurück. Es folgten die Versionen 2.1 (1999) und 2.2 (2000), die sich bis auf hinzugefügte Geschäftsvorfälle relativ wenig voneinander unterschieden.
Im Jahre 2002 wurde die Version 3.0 veröffentlicht und der Standard umbenannt in FinTS (Financial Transaction Services). Mit FinTS ist das Sicherheitsverfahren Pin/Tan sowie der Einsatz von Signaturkarten in den Standard hinzugekommen. Abgesehen davon galten die Strukturen aus den Vorversionen in ähnlicher Form weiter. In der Zwischenzeit hatte der Deutsche Sparkassenverband eine Version namens HBCI+ eingesetzt, bei ein Pin/Tan-Sicherheitsverfahren genutzt wurde. In der Version FinTS 3.0 wurde dieses Verfahren dann als alternative Sicherheitslösung in den FinTS-Standard aufgenommen, wie oben erwähnt.
Schließlich wurde im Jahre 2004 die Version FinTS 4.0 eingeführt. In dieser Version wurden alle internen Datenstrukturen komplett auf XML und XML-Schemata umgestellt, HTTPS als Kommunikationsprotokoll verwendet und weitere komplett neue Schnittstellen (z.B. WWW-Portale) eingeführt.
Listen von Banken, die HBCI anbieten, sind z.B. auf http://www.hbci.de/ oder auf OpenHBCI/GetesteteBanken zu finden.
1.2. Bestandteile des Standards
HBCI spezifiziert im wesentlichen zwei große Teilbereiche des Online-Banking: Einerseits werden mehrere Sicherheitsverfahren zur Authentifizierung und Verschlüsselung der Aufträge definiert, z.B. Chipkarten oder Pin/Tan. Andererseits sind mit Geschäftsvorfällen Datenformate und Abläufe für die Ausführung einzelner Bankgeschäfte festgelegt, z.B. Einzelüberweisung, Umsatzabruf eines Kontos, Änderung eines Dauerauftrags etc.
Seit der Umbenennung in FinTS wird die Bezeichnung "HBCI" für eine bestimmte Gruppe der Sicherheitsverfahren verwendet, indem die Chipkarten und RSA-Schlüsseldateien als "HBCI Sicherheitsverfahren" bezeichnet werden und vom Pin/Tan-Sicherheitsverfahren unterschieden werden. In den vorigen Versionen stand die Bezeichnung "HBCI" allerdings für die Gesamtheit der Geschäftsvorfälle zusammen mit allen bekannten Sicherheitsverfahren. Insofern wäre es durchaus angemessen, von einer Umbenennung von HBCI in FinTS zu sprechen.
1.3. Sicherheitsverfahren
1.3.1. RSA-Schlüsseldiskette
HBCI unterstützt Disketten oder andere Datenträger als Sicherheitsmedium für ein selbsterzeugtes RSA-Schlüsselpaar. Zum Zeitpunkt der ersten HBCI-Veröffentlichung war eine Diskette noch das vorherrschende beschreibbare Wechselmedium, so daß immer von der "Schlüsseldiskette" die Rede ist, obwohl jedes andere Speichermedium (z.B. USB-Stick) genauso gut zu Anwendung kommen kann.
Für die Authentifikation wird dabei in der Software des Kunden ein RSA-Schlüsselpaar mit 768 Bit erzeugt (HBCI2.x; ab FinTS3.0 auch 1024 bis 2048 Bit, genannt "Sicherheitsklasse RDH-2/3/4"). Danach wird vom Benutzer ein elektronischer Fingerabdruck (fingerprint) des öffentlichen Schlüssels auf Papier ausgedruckt und unterschrieben an die Bank gesendet. Gleichzeitig wird der öffentliche RSA-Schlüssel elektronisch an den HBCI-Server der Bank gesendet. Die Bank kann an Hand des unterschriebenen fingerprints sicherstellen, daß der elektronisch eingereichte Schlüssel auch tatsächlich und ausschließlich vom unterschreibenden Bankkunden stammt. Damit ist der selbsterzeugte Schlüssel auf sichere Weise authentifiziert und kann nun zur Signatur jedes Auftrages verwendet werden.
Zur Nachrichtenverschlüsselung kommt ein Triple-DES-Verfahren zum Einsatz. Für jede Nachricht wird ein neuer 128-Bit-Einmalschlüssel generiert, der dann mit den dauerhaften RSA- oder DES-Schlüssel verschlüsselt wird. Diese Vermischung des RSA- und DES-Verfahrens wird im HBCI-Standard als RSA-DES-Hybridverfahren (RDH) bezeichnet.
Das Speicherformat des RSA-Schlüssels auf dem Datenträger ist nicht im HBCI-Standard spezifiziert. Das Datenformat und ein eventueller Schutz per PIN wird von jedem Software-Hersteller alleine festgelegt, was häufig dazu führt, daß selbsterzeugte Schlüssel einer HBCI-Software nicht von konkurrierenden HBCI-Programmen weiterverwendet werden kann.
1.3.2. DES-Chipkarte
Die Authentifikation einer Chipkarte geschieht implizit dadurch, daß dem Bankkunden die Chipkarte überreicht wird. Die DES-Chipkarte enthält dabei DES-Schlüssel der Länge 128 Bit.
1.3.3. RSA-Chipkarte
Bei einer RSA-Chipkarte ergeben sich die gleichen Abläufe wie bei einer Schlüsseldiskette, außer daß der erzeugte RSA-Schlüssel durch den Prozessor auf der RSA-Chipkarte erzeugt wird und der private Schlüssel dadurch nie die Chipkarte verläßt. Dies macht dieses Verfahren besonders sicher, allerdings sind RSA-Chipkarten noch immer recht teuer.
1.3.4. Pin/Tan
Seit der Version FinTS3.0 können auch HBCI-Aufträge mit PIN und TAN authentifiziert werden. Wenn eine Bank entscheidet, wieder auf PIN/TAN als Authentifizierung zurückzugreifen, gibt es doch wieder Transaktionsnummern, aber kein Sicherheitsmedium. Allerdings haben viele Banken weiterhin nur Version 2.2, 2.1 oder sogar 2.01 implementiert. Bankeninfo darüber gibt es auf http://www.hbci.de/ oder zum Teil auch auf OpenHBCI.
1.3.5. Geschäftsvorfälle
Einzelüberweisung, Umsatzabruf eines Kontos, Änderung eines Dauerauftrags, etc.
- Mittels Bank-Parameter-Daten (BPD) und User-Parameter-Daten (UPD) meldet der HBCI-Server einer Bank konkret, welche Geschäftsvorfälle diese Bank im Allgemeinen und für diesen Benutzer im Besonderen erlaubt.
1.4. Besonderheiten
Bei HBCI übernehmen einige (wenige) Banken die Beweispflicht. Das würde heißen: Wenn beim Homebanking etwas schiefläuft, haftet erst einmal die Bank, außer sie kann explizit beweisen, dass es der Fehler des Benutzers war.
/FürEntwickler gibt es außer dem Standard manche Eigenheiten von diversen Banken zu beachten, die hier gesammelt werden.
2. Internationaler Vergleich
HBCI ist eine rein deutsche Erfindung. Wenn und solange es funktioniert, hat man ungeahnte Möglichkeiten der Verwaltung von Geschäftsvorfällen -- andere Länder (z.B. USA) können von so einer reichhaltigen Online-Funktionalität mit Multibankfähigkeit wirklich nur träumen1. Es bleibt abzuwarten, ob sich ähnliche Standards in Europa ausbreiten. Aber im Moment sollte man zumindest bei Online-Diskussionen gelegentlich im Hinterkopf behalten, daß HBCI wirklich nur innerhalb von Deutschland existiert.
3. HBCI unter Linux
3.1. Anwendungssoftware
3.1.1. FreieSoftware / OpenSource
GnuCash ist eine OpenSource/GPL-Finanzverwaltung für Linux/Unix, die seit dem Jahr 2003 (Version 1.8.0) HBCI unterstützt.
Hibiscus ist eine Java-basierte Homebanking-Anwendung für Linux und Windows, welche intern HBCI4Java verwendet. Lizenz: GPL.
MoneyPenny ist eine Homebanking-Anwendung, die auf einer Knoppix-Live-CD läuft. Lizenz: GPL.
QBankManager ist eine Qt-basierte Homebanking-Anwendung für Linux und (via Qt4) Windows (und die Referenzimplementation für AqBanking)
KMyMoney2 - in etwa wie GnuCash, nur für KDE mit etwas freundlicherem UI.
Eine inzwischen nicht mehr weiterentwickelte Kommandozeilen-Homebanking-Anwendung für Linux ist AqMoney, was auch die Referenzimplementation von OpenHBCI war. Diese Anwendung wird abgelöst von aqbanking-tool, welches Teil von AqBanking ist.
Grisbi, ein weiteres Finanzverwaltungsprogramm (GTK).
3.1.2. Kommerziell / ClosedSource
Die kommerzielle Software moneyplex von Matrica unterstützt HBCI.
StarMoney on Linux ist eine kommerzielle Lösung die unter Wine läuft. Bitte die Einschränkungen unter "Produktdetails" beachten. Unter Wine können bisher keine Chipkarten verwendet werden.
- Laut Starmoney wird die neue Version 7.0 nicht mehr unter Wine/Linux laufen, da es zu viele verschiedene Standards gibt und das zu viel Serviceaufwand bedeutet.
3.2. Bibliotheken
Die Bibliothek OpenHBCI war die erste freie Implementierung des HBCI Standard auf Linux, ist inzwischen aber durch AqBanking abgelöst worden.
AqBanking ist der Nachfolger von OpenHBCI und wird vom gleichen Entwicklerteam weiter verbessert. Diese Bibliothek bietet die Grundlage z.B. für GnuCash. Auch hier muss sich der Anwendungsprogrammierer nicht mit den Interna des HBCI-Protokolles auseinandersetzen. Es enthält bereits vorgefertige GUI-Klassen fuer QT3, KDE3, GTK2 und Konsolenanwendungen. Damit ist es insbesondere für QT- und KDE-Anwendungen sehr einfach, Online-Banking Funktionalität hinzuzufügen.
HBCI4Java ist eine OpenSource/GPL-Klassenbibliothek für Java. Diese Bibliothek ist besonders einfach zu handhaben für Entwickler, die HBCI-Funktionen benutzen möchten, sich aber nicht mit den Details von HBCI selbst beschäftigen wollen. Außerdem wird hier sowohl ein Framework für die Erstellung eines eigenen HBCI-Servers wie auch ein damit implementierter HBCI-Demo-Server bereitgestellt.
4. Weitere Informationen
- In der c't 19/2002 ist ein fünfseitiger Artikel zum Onlinebanking zu finden, bei dem auch HBCI und HBCI-PIN/TAN behandelt werden.
Eine Liste mit den Einstellungen vieler Banken gibt es auch im onlinebanking-forum, wo man sich auch bei Problemen mit Leidensgenossen austauschen kann.
/FürEntwickler gibt es außer dem Standard manche Eigenheiten von diversen Banken zu beachten, die hier gesammelt werden.
Wenn manche USA-Programme trotzdem einen großen Online-Banking Funktionsumfang bieten, dann geht das wirklich nur dadurch, daß der jeweilige Hersteller eben entsprechende Vereinbarungen mit der jeweiligen Bank abgeschlossen hat. Kleine Hersteller oder gar OpenSource-Projekte gucken auf jeden Fall in die Röhre. Und als Kunde ist man dann an die jeweilige Kombination Anwendungssoftware und Bank festgebunden. (1)