OpenHBCI ist eine OpenSource-Implementierung des deutschen Online-Banking-Protokolls HBCI.

Inhalt

1. Einführung

OpenHBCI ist eine OpenSource-Implementierung der Client-Seite des deutschen Online-Banking-Protokolls HBCI. OpenHBCI ist jedoch kein Homebanking-Programm, sondern eine Funktionsbibliothek, die Homebanking-Funktionalität bietet. In dieser Bibliothek werden die HBCI-Versionen 2.01, 2.1 und teilweise 2.2 unterstützt.

Entwicklung eingestellt: Als Nachfolger von OpenHBCI wurde vom selben Autorenteam das neue Bibliothekpaket AqBanking/AqHBCI entwickelt. Dieses bietet einen größeren Funktionsumfang und eine breitere Verwendungsmöglichkeit. Die Weiterentwicklung von OpenHBCI wurde daher im Laufe des Jahres 2004 eingestellt. Bitte versuchen Sie, ebenfalls auf AqBanking umzusteigen, und stellen Fragen und Anregungen nur noch auf dessen Projektseite (Aber die Mailingliste openhbci-general wird auch für das neue Projekt weiterverwendet).

OpenHBCI unterstützt mehrere Sicherheitsmedien. Teilweise werden dabei zusätzliche Plugins benötigt:

• OpenHBCI-Schlüsseldateien werden immer unterstützt.

• DDV-Chipkarten werden unterstützt, aber dafür müssen zusätzlich das Paket openhbci-plugin-ddvcard sowie die Bibliothek LibChipCard installiert werden.

• Für proprietäre SIZ-Sicherheitsdisketten (Schlüsseldateien, z.B. von Star-Money u.a.) ist ein binary-only plugin erhältlich, siehe Homepage (Stand: 2003-08-26).

• RSA-Chipkarten werden nicht unterstützt (s.u. Chipkarten) (sie werden aber von AqBanking/AqHBCI unterstüzt).

• Andere proprietäre Schlüsseldateien (z.B. von Quicken oder Moneyplex) werden ebenfalls nicht unterstützt (s.u.).

• PIN/TAN wird weiterhin nicht unterstützt.

Homepage: http://www.openhbci.de/

Mailingliste: http://lists.sourceforge.net/lists/listinfo/openhbci-general (Diese Mailingliste wird auch für das neue Projekt AqBanking weiterverwendet)

Lizenz: LGPL

Download auf sourceforge.net, Debian Pakete, RedHat 9 Pakete

Homebanking-Programme, die OpenHBCI verwenden:

• GnuCash von Version 1.8.0 (Februar 2003) bis 1.8.9 (November 2004)

• AqMoney als Kommandozeilentool

• LxBank

• GopenHBCI

• KOpenHBCI

2. Tipps & Tricks

Entwicklung eingestellt: Als Nachfolger von OpenHBCI wurde vom gleichen Autorenteam das neue Bibliothekpaket AqBanking/AqHBCI entwickelt. Dieses bietet einen größeren Funktionsumfang und eine breitere Verwendungsmöglichkeit. Die Weiterentwicklung von OpenHBCI wurde daher im Laufe des Jahres 2004 eingestellt. Bitte versuchen Sie, ebenfalls auf AqBanking umzusteigen, und stellen Fragen und Anregungen nur noch auf dessen Projektseite (Aber die Mailingliste openhbci-general wird auch für das neue Projekt weiterverwendet).

2.1. Chipkarten

2.1.1. Wird meine Chipkarte unterstützt?

OpenHBCI unterstützt derzeit nur sogenannte DDV-Karten. Die im Umlauf befindlichen RSA-Karten werden derzeit noch nicht unterstützt (siehe unten, "Detailinformationen: Chipkarten für HBCI"). Mit dem folgenden Kommando kann man feststellen, ob die Karte unterstützt wird:

hbcicard type

Bei einer DDV-0-Karte wird in etwa folgendes ausgegeben:

Please insert your HBCI card into any reader
Card is inserted, working.
Card type is: DDV-0 card

Bei einer DDV-1-Karte ist die Ausgabe:

Please insert your HBCI card into any reader
Card is inserted, working.
Card type is: DDV-1 card

Beide Kartentypen werden unterstützt. Kommt aber die folgende Ausgabe:

Please insert your HBCI card into any reader
Card is inserted, working.
Card type is: RSA card

kann die Karte leider nicht mit OpenHBCI verwendet werden. Genauer: Es kann zwar Kontakt zur Karte aufgenommen werden (wie man anhand der Ausgabe von hbcicard sieht), aber die RSA-Karte kann weiterhin nicht für die HBCI-Verschlüsselung verwendet werden.

Aber: In vielen Fällen kann man dann trotzdem OpenHBCI verwenden, nämlich im Schlüsseldatei-Modus. Für die Bank macht es nämlich keinen Unterschied, ob die Schlüssel in einer Datei oder auf einer Karte gespeichert sind. Diese Möglichkeit entfällt allerdings, wenn die Bank die Benutzerschlüssel bereits auf der Karte erzeugt hat, denn an diese Schlüssel kann man von außen nicht mehr gelangen. In diesem Fall ist Homebanking mit OpenHBCI leider wirklich nicht machbar.

2.1.2. User-ID in der Chipkarte setzen

Manche Banken liefern Chipkarten aus, bei denen noch keine Benutzerkennung (User ID) gesetzt wurde. Dies führt dann zu der Fehlermeldung "could not select context (owner2)", so daß z.B. bei GnuCash auf der Konsole die Meldung erscheint: gnc_hbci_api_execute: Error at executeQueue: could not select context (owner2) 

In diesem Fall muß nun der Karteninhalt kontrolliert werden. Folgendes Kommando muß auf der Kommandozeile eingegeben werden:

hbcicard dump

Dies könnte sowas wie die folgenden Zeilen ergeben:

Data is: 
 Country       : 280 
 Institute Name: <Name_der_Bank> 
 Institute Code: <Bankleitzahl> 
 Service Type  : TCP 
 IP Address    : <Adresse_des_Servers> 
 IP Port       : 
 User ID       : 

Die Zeile mit der User ID: zeigt durch den leeren Eintrag, daß auf der Chipkarte wirklich noch keine Benutzerkennung (User ID) gesetzt wurde. Deshalb muß nun die Benutzerkennung, die einem von der Bank mitgeteilt wurde, dort manuell reingeschrieben werden. Dies geschieht durch einen der folgenden Aufrufe:

Wenn man ein Kartenterminal mit eigener PIN-Tastatur hat:

hbcicard set -i 1 -u <meine_benutzerkennung> -k

Wenn man ein Kartenterminal ohne PIN-Tastatur hat:

hbcicard set -i 1 -u <meine_benutzerkennung> -p <meine_pin>

2.2. HBCI Version ändern

Einige Banken unterstützen mehrere Versionen der HBCI-Spezifikation (z.B. 2.01, 2.1 oder 2.2), aber manche HBCI-Funktionen sind dann nicht in allen dieser Versionen verfügbar. OpenHBCI benutzt als Voreinstellung die niedrigste (d.h. älteste) der unterstützten Versionen. Wenn sich herausstellen sollte, daß dann einige Funktionen (z.B. Abruf des Kontostandes) nicht wie gewünscht funktionieren, muß man auf eine höhere (d.h. neuere) HBCI-Version wechseln.

2.2.1. Mit AqMoney

Das Tool AqMoney hat dazu ein eigenes Kommando: --command=chgversion. Dazu gibt man die zu verwendende HBCI Protokoll-Version mit dem Schalter --hversion=XYZ an. Als Werte für XYZ sind die folgenden zulässig:

und so weiter. Die Bank, bei der man die Protokoll-Version ändern möchte, gibt man wie üblich mit --institute=<meine_BLZ> an. Ein vollständiges Kommando sähe also beispielsweise so aus:

 aqmoney --command=chgversion --hversion=210 --institute=<meine_BLZ>

AqMoney verbindet sich daraufhin mit der Bank und aktualisiert die nötigen Daten.

2.2.2. Mit GnuCash

In GnuCash ist dafür ein Knopf im HBCI Einrichtungsassistent vorgesehen.

2.2.3. HBCI Version manuell ändern

Falls die eben genannten Möglichkeiten fehlschlagen sollten, oder wenn OpenHBCI über ein anderes Programm verwendet wird, muß der Versionswechsel manuell vorgenommen werden. Dazu muß der entsprechende Abschnitt [bank/<Nummer der Bank>] in der Konfigurationsdatei von OpenHBCI geändert werden.

Zum Beispiel könnte die erste Bank (Nummer 0) und die erste Benutzerkennung (Nummer 0) betroffen sein. In der Konfigurationsdatei ~/.openhbci stünden unter andereren auch Zeilen wie die folgenden:

 [bank/0]
 hbciversion="201"

 [bank/0/params]
 version="5"
 country="280"
 code="<Bankleitzahl>"
 name="<Name_der_Bank>"
 hbciversions="210"
 hbciversions="201"

 [bank/0/user/0]
 version="4"

Man erkennt in der Zeile hbciversion="201", daß zur Zeit die Version 2.01 benutzt wird. Man erkennt außerdem weiter unten in den Zeilen hbciversions="210" und ="201", daß diese Bank insgesamt die Versionen 2.1 und 2.01 unterstützt. Nun kann der Eintrag hbciversion wie gewünscht geändert werden.

Zusätzlich muß aber noch die Zahl in der Zeile version="..." in den Abschnitten [bank/0/params] und sicherheitshalber auch [bank/0/user/0] auf Null gesetzt werden. Dies bedeutet, daß die Bankdaten, die OpenHBCI vorliegen, dann nicht mehr als aktuell betrachtet werden und deshalb automatisch neu angefordert werden. (Denn die vorliegenden Daten galten nur für die alte HBCI Version.) Die geänderten Zeilen würden dann so aussehen:

 [bank/0]
 hbciversion="210"

 [bank/0/params]
 version="0"

 [bank/0/user/0]
 version="0"

Nach dem Abspeichern muß die verwendete HBCI-Software die Bankdaten neu anfordern. Bei aqmoney geschieht das mit dem Befehl "sync". Bei GnuCash geschieht das durch Anklicken des Knopfes "Kontoliste abrufen" im HBCI Einrichtungsassistent.

2.3. Benutzerkennung ungültig (9210:7,3:Inhaltlich ungültig)

Einige Anwender haben beim Einrichten eines neuen HBCI-Zugangs folgende Rückmeldung von der Bank beobachtet:

HIRMS(Rückmeldung zu Segmenten)            :3:2:998+9210:7,3:Inhaltlich ungültig.'

Die Zahlenkombination 7,3 (vor den Worten Inhaltlich ungültig) deutet darauf hin, daß die Benutzerkennung fehlerhaft war. Anscheinend akzeptiert der Server diese einfach nicht. Wahrscheinlich existiert eine falsche Benutzerkennung auf dem verwendetem Medium (Chipkarte oder Schlüsseldiskette), oder die Bank hat sie noch nicht freigeschaltet (z.B. könnte die Empfangsbestätigung für die PIN vergessen worden sein). Abhilfe: Benutzerkennung nochmal kontrollieren und eventuell korrigieren oder bei der Bank nachfragen, ob die betreffende Benutzerkennung überhaupt freigeschaltet ist.

2.4. Das Plugin-System von OpenHBCI

Seit Version 0.9.10 bietet OpenHBCI ein Plugin-System für Sicherheitsmedien an. Dabei wird die Unterstützung für Sicherheitsmedien bei Bedarf jeweils als Modul nachgeladen.

Standardmäßig liefert OpenHBCI ein Plugin für die bisherigen Schlüsseldateien mit. Für die Benutzer von Schlüsseldateien ändert sich also überhaupt nichts.

Auf der Download-Seite werden aber auch weitere Plugins angeboten, beispielsweise für DDV Chipkarten (openhbci-plugin-ddvcard). Wenn man also solche Chipkarten verwenden möchte, muss man einfach das entsprechende Plugin-Paket downloaden und installieren. Benutzer von Chipkarten, die bisher die Chipkarten-Unterstützung gleich in OpenHBCI mit dazukompiliert hatten, müssen also jetzt zusätzlich das Paket openhbci-plugin-ddvcard herunterladen und installieren.

Das erlaubt uns, später auch Sicherheitsmedien zu unterstützen, für die wir keinen Sourcecode veröffentlichen dürfen. Außerdem kann OpenHBCI damit grundsätzlich neue Medien unterstützen, ohne daß es selbst neu kompiliert werden muß.

2.4.1. Plugins und alte GCC-Systeme

Durch Fehler im GCC-Compiler mit Versionen kleiner als 3.0 können solche Systeme keine Plugins nachladen. Dabei handelt es sich insbesondere um Debian Woody, SuSE 8.0 und älter sowie Redhat vor 8.0. Um auf diesen Systemen aber dennoch mit der aktuellen Version von OpenHBCI zu arbeiten, muß man folgendermaßen vorgehen:

• OpenHBCI tarball laden und entpacken

• gewünschtes Plugin laden und in das Unterverzeichnis ext_plugins des OpenHBCI-Quellcode-Pakets entpacken

• ./configure aufrufen. Dieses Skript findet dann alle Plugins, die in das Verzeichnis kopiert wurden. Die gefundenen Plugins werden "statisch" zu OpenHBCI hinzugelinkt, so daß diese Plugins nicht zur Laufzeit nachgeladen werden müssen, aber trotzdem für alle Programme zur Verfügung stehen.

2.5. Programmabsturz (Segfault) nach OpenSSL-Update

Problembeschreibung: Mit den neuesten Versionen von OpenSSL kommt es bei jeder HBCI-Aktion zum Programmabsturz¹. Eine Sicherheits-Änderung in OpenSSL vom Februar 2003 veränderte das Verhalten der Bibliothek derart, daß die entsprechenden Funktionsaufrufe von OpenHBCI jetzt immer zum Programmabbruch (Segfault) führen. Dieser Programmabbruch wurde beobachtet mit allen Versionen seit 0.9.6h, also auch in der aktuellen Version 0.9.7b, und teilweise auch in 0.9.6g mit Sicherheits-Patches vom März 2003. In SuSE 8.1 tritt mit dem Paket openssl-0.9.6g-68 der Fehler auf, mit dem Paket openssl-0.9.6g-55 (zu finden hier) tritt dagegen kein Fehler auf.

Fehlerbehebung: Seit 18. Mai ist die OpenHBCI-Version 0.9.11 verfügbar², in der der Fehler korrigiert ist. Ein Update auf diese Version behebt den Fehler.

2.6. Fehler mit aqmoney bei Jahreswechsel

Problembeschreibung: Nach einem Jahreswechsel kann es mit aqmoney (stable) beim Abholen von Kontodaten (aqmoney turnover) zu folgender Fehlerausgabe kommen:

Ergebnis: Von Datum ist größer als das heutige Datum. (MDC15100200020) (Code 9010)

Fehlerbehebung: Durch einmaligen Aufruf von aqmoney turnover mit festem Startdatum (--fromdate) kann das Problem behoben werden.

3. Mit OpenHBCI getestete Banken

siehe /GetesteteBanken

Die Einrichtung des HBCI-Zugangs ist hier beispielhaft mit dem Programm aqmoney unter /GetesteteBanken/VolksbankZuffenhausen erläutert.

Die Einrichtung des HBCI-Zugangs ist ebenfalls dort beispielhaft mit dem Programm 'aqmoney2' unter /GetesteteBanken/DresdnerBank erläutert.

4. Wunschliste neuer Features

Entwicklung eingestellt: Als Nachfolger von OpenHBCI wurde vom selben Autorenteam das neue Bibliothekpaket AqBanking/AqHBCI entwickelt. Dieses bietet einen größeren Funktionsumfang und eine breitere Verwendungsmöglichkeit. Die Weiterentwicklung von OpenHBCI wurde daher im Laufe des Jahres 2004 eingestellt. Bitte versuchen Sie, ebenfalls auf AqBanking umzusteigen, und stellen Fragen und Anregungen nur noch auf dessen Projektseite (Aber die Mailingliste openhbci-general wird auch für das neue Projekt weiterverwendet).

In dieser Tabelle sollen mal die gelegentlich geäußerten Wünsche zusammengetragen werden, nach welche Features denn am häufigsten gefragt wird und was geschehen müsste, damit die eingebaut werden können.

Die Spalte "Aufwand" bezieht sich auf netto-Programmier-Stunden und entspricht, wie der Name schon sagt, eben nur einer ganz groben Schätzung.

DTAUS Hinweis: Es existieren lt. http://www.nerdbank.org mindestens zwei GPL implementierungen: http://www.infodrom.org/projects/dtaus/index.php3 und http://www.ffii.org/~phm/toad. OpenHBCI verwendet eine eigene Implementierung eines DTAUS Parser.

Ausserdem vielleicht noch interessant, der Hinweis auf Förderung offener Bankenschnittstellen des FFII e.V. : http://egeld.ffii.org

4.1. Fragen zu neuen Features

Entwicklung eingestellt: Als Nachfolger von OpenHBCI wurde vom selben Autorenteam das neue Bibliothekpaket AqBanking/AqHBCI entwickelt. Dieses bietet einen größeren Funktionsumfang und eine breitere Verwendungsmöglichkeit. Die Weiterentwicklung von OpenHBCI wurde daher im Laufe des Jahres 2004 eingestellt. Bitte versuchen Sie, ebenfalls auf AqBanking umzusteigen, und stellen Fragen und Anregungen nur noch auf dessen Projektseite (Aber die Mailingliste openhbci-general wird auch für das neue Projekt weiterverwendet).

• Frage: Gibt es eine Erweiterung um openHBCI einfacher für PHP zu nutzen? (s3rverop, 16.06.2003) Antwort: Was ist denn damit gemeint ? Was brauchst Du denn genau ? (MartinPreuss, 24.06.2003) Antwort: Nein, gibt es leider nicht. mit PECL_Gen von http://pear.php.net sollte sich sowas aber einfach machen lassen. Die PHP-Extension müsste wohl fast nur die OpenHBCI API wrappen.. (HannesGassert, 21.03.2004)

• Frage: Was soll ein 'Plugin-System für Medium' genau sein? (Joern 'Wulf' Heissler, 13.04.2003) Antwort: Mit einem Plugin-System ist gemeint, daß binary-only "plugins" für weitere Medien benutzt werden können. Es geht da praktisch um die RSA-Karte, wo man die Spezifikation zwar bekommen kann, aber gleichzeitig entsprechende Vertraulichkeitserklärungen unterschreiben muß. Wenn man den Programmcode der Implementierung dann via OpenSource weitergeben würde, würde man gegen diese Vertraulichkeitserklärung verstoßen. Wenn man nur eine binary-only Version der Implementierung weitergeben würde, könnten auch die Bankenverbände damit leben. (ChristianStimming, 16.04.2003)

• Frage: Ich such momentan eine einfache Möglichkeit, Medien(RDH-Disketten) von anderer Software (z.B. Star-Money) in das openhbci-Format zu konvertieren, und bin auch gerne bereit da was zu programmieren. Wie erzeuge ich ein neues openhbci-medium, dem ich die ganzen Daten (Eigene-/Bankschlüssel, kommunikationsadresse, kundensystem-id, etc.) einfach übergeben kann? (Joern 'Wulf' Heissler, 13.04.2003) Antwort: Siehe http://www.linuxwiki.de/GnuCash#fremdeHBCIProgramme Die Schlüsseldateien und -disketten aus anderen Onlinebanking-Programmen (z.B. Quicken, StarMoney, moneyplex) können nicht in GnuCash/OpenHBCI/AqBanking weiterverwendet werden. -- ChristianStimming 2005-02-26 10:33:23

• Frage: Ist eine Unterstützung für die VR-NetWorld Card (prop. RSA von Giesecke & Devrient) geplant bzw. ist eine Lösung für diese Kartenlösung absehbar? (tuXXer, 2004-03-04)

• Frage: Werden Überweisungen mit IBAN unterstützt (besteht ein Zusammenhang mit "country code" aus aqmoney?) ? Falls nein, wird die Funktion in Deutschland überhaupt von den Banken über HBCI angeboten? (KaiLangheim, 17.05.2004) Antwort: Nein, Euro-Überweisungen (mit IBAN) werden bisher nicht unterstützt. Der Country-Code aus aqmoney hat mit länderübergreifenden Überweisungen nichts zu tun. Trotzdem: In HBCI 2.2 ist der Geschäftsvorfall Euro-Überweisung vorhanden, aber uns ist nicht bekannt, ob und welche Banken dies in ihrem HBCI-Server auch unterstützen. In die Reihe OpenHBCI-0.9.x wird dieser Geschäftsvorfall sicherlich nicht mehr eingebaut. In der neuen OpenHBCI2-Reihe ist er ebenfalls bisher nicht vorhanden, könnte aber recht flott eingebaut werden, allerdings geschieht dort im Moment auch recht wenig. Fazit: Bisher nicht vorhanden und auch kurzfristig nicht zu erwarten. -- ChristianStimming 2004-05-17 09:17:22 Nachtrag: Ein Mitarbeiter der Deutschen Bank meinte soeben am Telefon, dass IBAN-Überweisungen innerhalb der EU unterstützt werden. Ich teste es aber gleich erstmal über die bankeigene Software DB-Dialog. (KaiLangheim, 21.05.2004) Ob die Bank Euro-Überweisungen über HBCI unterstützt, kann man aus der openhbci-tng.conf ablesen. Ist dort beim jeweiligen Konto ein updjob { job="HKAOM" ... } vorhanden, dann wäre es prinzipiell möglich. Wann Unterstützung dafür in openhbci/aqmoney eingebaut werden kann ist allerdings offen. Ich habe vor August-September vermutlich keine Zeit mir das anzusehen. -- RonnyBuchmann 2004-05-17 17:57:29

• Frage: Ist eine Unterstützung für die HBCI / FinTS 3.0 geplant ? Insbesondere wäre ich an der Authentifizierung via PIN/TAN interessiert, die ja hier eingeführt wurde, denn "meine" Bank (die netbank) unterstützt nur diese Methode. (EisBär, 04.06.2004) Antwort: Ja, im Prinzip schon. PIN/TAN für HBCI 2.2 wird zumindest schon jetzt von AqBanking/AqHBCI (dem Nachfolger von OpenHBCI) angeboten. FinTS 3.0 wird allerdings bisher noch von keiner mir bekannten Bank eingesetzt, daher wird auch noch nicht am Client-Support dafür gearbeitet (MartinPreuss, 10.09.2004) Ergänzung: Die Sparda Banken (zumindest die Sparda Nürnberg) unterstützen nur PIN/TAN. (Hartmut Goebel, 2004-09-14)

• Frage: Ich hab bei Einzeltransaktionen bei aqmoney2 in der transaction-log die Felder: char statusCode="done"; char resultCode="success"; Nicht selten (4-6 / Monat) steht bei char resultCode="failed". Die Chance, dass die Lastschrift/Überweisung ausgeführt wurde besteht aber trotzdem noch zu 70%. Wo besteht der Unterschied zwischen Status/Resultcode? (KaiLangheim, 09.09.2004)

• Frage: Wird bei einem Kontoauszug je Buchungszeile auch eine eindeutige ID von der Bank übertragen? Ich übertrage die Daten in eine MySQL-Datenbank und ruf Auszüge zur Sicherheit rückwirkend doppelt ab. Derzeit bau ich mir aus Text+Datum+Betrag Prüfsummen. Wenn ich jedoch eine Überweisung zweimal mit gleichem Buchungstext/Betrag/Tag bekomme, hab ich ein Problem (KaiLangheim, 09.09.2004) Antwort: Leider gibt es eine solche eindeutige Id nicht. In aktuellen AqBanking-Anwendungen (wie QBankManager) kann zwar bisher sicher mit Doppel-Einreichungen umgegangen werden, aber dazu wird notfalls die Benutzer-Intervention nötig (dieser Fall tritt zwar selten auf, ist aber dennoch vorstellbar). (MartinPreuss, 10.09.2004)

• Frage: Ich habe bereits im StarMoney mein Konto eingerichtet und eine HBCI Diskette erstellt. Den Hash-Key hat meine Bank schon. Ich möchte nun OpenHBCI parallel verwenden. Geht dies und wenn ja, was muss ich beachten wenn ich ein neues OpenHBCI Keyfile erstelle? (MarioWeber, 25.02.2005) Antwort: Siehe http://www.linuxwiki.de/GnuCash#fremdeHBCIProgramme Die Schlüsseldateien und -disketten aus anderen Onlinebanking-Programmen (z.B. Quicken, StarMoney, moneyplex) können nicht in GnuCash/OpenHBCI/AqBanking weiterverwendet werden... Mehr siehe auf jener Seite. -- ChristianStimming 2005-02-26 10:33:23

Entwicklung eingestellt: Als Nachfolger von OpenHBCI wurde vom gleichen Autorenteam das neue Bibliothekpaket AqBanking/AqHBCI entwickelt. Dieses bietet einen größeren Funktionsumfang und eine breitere Verwendungsmöglichkeit. Die Weiterentwicklung von OpenHBCI wurde daher im Laufe des Jahres 2004 eingestellt. Bitte versuchen Sie, ebenfalls auf AqBanking umzusteigen und stellen Fragen und Anregungen nur noch auf dessen Projektseite. (Aber die Mailingliste openhbci-general wird auch für das neue Projekt weiterverwendet.)

4.2. Finanzielle Unterstützung

Siehe auch auf cstimming.de.

Frage: Kann man durch finanzielle Unterstützung die Entwicklung beschleunigen? -- RonnyBuchmann 2003-08-16 07:07:51 Antwort: Finanzielle Unterstützung kann auf zwei Arten geliefert werden:

1. Zum einen kann ein Geldbetrag als Geschenk den Entwicklern zugeschickt werden, so daß diese im Nachhinein eine nette Anerkennung ihrer bereits abgelieferten Arbeit erhalten.

2. Zum anderen kann einem Entwickler ein Geldbetrag zur Verfügung gestellt werden, die es ihm ermöglichen soll, eine (vorher ausgehandelte) Anzahl Arbeitsstunden auf OpenHBCI zu verwenden. Diese Möglichkeit wird auf jedem Fall zur Beschleunigung der Entwicklung beitragen!

Für letzteres steht z.B. Martin Preuß gerne zur Verfügung, ChristianStimming dagegen zur Zeit nicht. In allen Fällen soll der Unterstützer bitte einen Entwickler seiner Wahl direkt kontaktieren.

Der Unterstützer braucht dabei keine Bedenken zu haben, daß durch die Auswahl von einem Entwickler die anderen vielleicht zu kurz kommen würden -- der kontaktierte Entwickler wird schon Bescheid sagen, wenn eine Zuwendung besser an einen anderen Entwickler gerichtet werden soll. Und schließlich profitieren alle Entwickler von der abgelieferten Arbeit. -- ChristianStimming 2003-08-18 09:35:04

Und FreieSoftware allgemein und ohne Mehrkosten unterstützen: Mit Bücherbestellungen über bookzilla.de

5. Detailinformationen

5.1. HBCI Verschlüsselung

Soll eine HBCI Nachricht übertragen werden, so erzeugt der Sender einen temporären 128-Bit Nachrichtenschlüssel (auch session key genannt) und verschlüsselt damit die Nachricht im symmetrischen 2-Key-Triple-DES Algorithmus. Der temporäre Nachrichtenschlüssel, der zum Entschlüsseln der Nachricht wieder nötig ist, wird dann mit einem permanenten Schlüssel verschlüsselt und mit der verschlüsselten Nachricht mitgeliefert.

In HBCI wird angestrebt, daß die Nachrichtenschlüssel durchgehend mit einer RSA-Chipkarte auf Basis der gegebenen RDH-Spezifikationen (RSA-DES-Hybridverfahren) verschlüsselt werden sollten. (RSA chip card) Der aus dem öffentlichen/privaten Schlüsselpaar bestehende Schlüssel im RDH-Verfahren ist im HBCI-Standard immer 768 Bit (96 Bytes) lang. Die RSA-Chipkarten sind aber (noch) ziemlich teuer (siehe auch nächster Abschnitt).

Eine kostengünstige Alternative zu den RSA-Chipkarten ist die RDH-Softwarelösung, wo die RSA-Schlüssel per Software im PC erzeugt werden und in einer Datei gespeichert werden. Der private Schlüssel wird hier in verschlüsselter Form meist auf einer "Schlüsseldiskette" gespeichert. Der Schlüssel bleibt dabei aber prinzipiell auch für andere Software auf dem PC lesbar, was dieses Verfahren theoretisch verwundbar für Trojaner und ähnliches macht. ( RDH key file)

Als weitere kostengünstige Alternative existieren Chipkarten für die symmetrische Verschlüsselung des Nachrichtenschlüssels, was als DES-DES-Verfahren (DDV) bezeichnet wird. Hier wird der Nachrichtenschlüssel von der Chipkarte wieder per 2-Key-Triple-DES Algorithmus verschlüsselt. Dafür wird ein permanenter vom Kreditinstitut ausgegebener symmetrischer 128-Bit Schlüssel verwendet.

5.2. Chipkarten für HBCI

RSA-Chipkarten für das RSA-DES-Hybrid (RDH) Verfahren enthalten einen leistungsfähigen Mikroprozessor, der selbstständig RSA-Schlüssel erzeugen kann und die RSA-Verschlüsselung berechnen kann. Die Chipkarte dient also nicht bloß als Speichermedium, sondern berechnet die vollständige Verschlüsselung selber und kann vor allem das notwendige Schlüsselpaar aus öffentlichem und privatem Schlüssel selber erzeugen. Die Software übergibt die Klartextmeldung an die Chipkarte und erhält das verschlüsselte Ergebnis sowie den öffentlichen Schlüssel zurück, so daß der private Schlüssel des RSA-Schlüsselpaares niemals die Chipkarte verläßt. Dies macht diese Verschlüsselungsmethode sehr sicher. Nachteilig ist aber, daß RSA-Chipkarten (noch) ziemlich teuer sind. Und zusätzlich scheinen ziemlich viele unterschiedliche Spezifikationen/Versionen von RSA-Chipkarten in Benutzung zu sein (siehe unten).

Billiger sind die DDV-Chipkarten für das DES-DES-Verfahren (DDV), wo beide Kommunikationspartner den gleichen (geheimen) Schlüssel kennen müssen. Dieser geheime Schlüssel wird im Institut erzeugt und vom Institut auf die Karte geschrieben. Auch hier berechnet der Mikroprozessor auf der Karte die Verschlüsselung selber: Die Software übergibt die Klartextmeldung an die Chipkarte und erhält das verschlüsselte Ergebnis zurück. Auch hier kann der Schlüssel nicht ausgelesen werden und ist somit vor Trojanern und ähnlichem sicher, aber im Gegensatz zu den RSA-Karten ist hier der geheime Schlüssel prinzipbedingt mindestens einer weiteren Partei (nämlich dem Institut) bekannt.

Ein Vorteil der DDV-Karten ist, daß sie schon eine Weile am Markt sind und die Spezifikationen keinen unerwarteten Änderungen mehr unterworfen sind. Der Nachteil gegenüber RSA-Karten ist in der Praxis allerdings, dass man die Schlüssel nicht selber erzeugen kann, was bei den RSA-Karten ja der Fall ist -- man ist also an das kartenausgebende Institut gebunden. Diesen Vorteil der RSA-Karten machen einige Banken wiederum dadurch zunichte, dass sie ihre RSA-Karten ebenfalls gleich mit Schlüsseln ausliefern und diese mit Hilfe der EG-Pin (siehe unten) gegen Änderungen durch den Benutzer sperren.

Der Rest dieses Abschnitts soll über Details der verschiedenen RSA-Karten, die z. Zt. auf dem Markt erhältlich sind, informieren. Da sich Angaben dieser Art im Internet rar machen, bitte ich jeden, der noch etwas dazu beitragen kann, dies auch zu tun! (Florian Wobbe, 11.04.2003)

5.2.1. Allgemeines zu RSA Karten

RSA-Chipkarten werden von den Banken in den verschiedensten Ausführungen angeboten. Da kein einheitlicher Standard über Datenformat und Zugriffsbedingungen/-vorgängen verfügbar ist, an den man sich halten müsste, entstehen auf der Anwender-Seite erhebliche Probleme beim Einsatz dieser Chipkarten. RSA-Chipkarten werden derzeit noch nicht von OpenHBCI unterstützt.

Eine Eigenheit dieser Karten besteht darin, dass sie zwei Pins besitzen: Zum einen die sogenannte Cardholder-Pin, die vom Benutzer geändert werden kann und die den Zugriff auf die Karte schützt. Darüber hinaus gibt es noch die Endgeräte-/Gateway-Pin (EG-Pin), die benötigt wird, um auf der Karte Daten zu ändern.

Normalerweise bleibt die EG-Pin auf dem vom Hersteller festgelegten Initialwert, damit man die Karte mit unterschiedlichen Programmen verwenden kann, denn geschützt ist die Karte ja weiterhin durch die Cardholder-Pin. Aber die Existenz der EG-Pin wird momentan von einigen Banken - die diese Chipkarten an Neukunden vergeben - dahingehend ausgenutzt, dass die EG-Pin von der Bank verändert wird. Dadurch ist es nicht mehr möglich, die Chipkarte mit einem anderen HBCI-fähigen Programm zu nutzen als mit jenem, das die Bank dem Neukunden mitgegeben hat. Eine Verwendung mit OpenHBCI und LibChipCard wäre also dann nicht mehr möglich.

Es wäre prima, wenn es eine Möglichkeit gäbe, diese Pin auf den Initialwert zurückzusetzen -- andererseits würde dies dem Sinn einer Pin widersprechen. Beim jetzigen Stand der Dinge können RSA-Chipkarten nur dann mit OpenHBCI bzw. LibChipCard benutzt werden, wenn gewährleistet ist, daß die EG-Pin noch ihren Initialwert hat.

5.2.2. RSA-Chipkarten-Typen unterschiedlicher Banken

Wie sich herausgestellt hat, gibt es eine neue Generation von RSA-Karten, die im Folgenden als zweite Generation bezeichnet werden. Ob es sich um eine RSA-Karte erster oder zweiter Generation handelt kann man nach Martin Preuß' Meinung an der Anzahl der zur Verfügung stehenden Fehlversuche bei der PIN-Eingabe erkennen. Diese Information erhält man durch die Eingabe folgenden Komandos:

hbcicard pinstatus

Dabei weisen drei verfügbare Fehlversuche auf eine RSA-Karte der ersten Generation und fünf verfügbare Fehlversuche auf eine RSA-Karte der zweiten Generation hin (Deutsche Bank Bielefeld 8!).

Libchipcard kann mit den RSA-Karten der ersten Generation umgehen, mit denen der zweiten jedoch noch nicht.

Hinweis: Damit die Tabelle nicht zu breit wird können die Karten wie folgt codiert werden... 1=leer, 2=vorpersonalisiert, 1e=leer+EG-Pin, 2e=vorpersonalisiert+EG-Pin. Werden mehrere Karten angeboten, so sind diese mit Semikolon voneinander zu trennen.

5.2.3. Bezugsquellen für RSA-Chipkarten

Eine Möglichkeit, die Chipkarten-Verschlüsselung trotzdem zu nutzen, ist, der Bank mitzuteilen, man wolle das RSA-Schlüsseldatei-Vefahren nutzen. In diesem Verfahren werden die Schlüssel erst vom Benutzer per Bankingsoftware erzeugt, an die Bank geschickt und mit einem Ini-Brief bestätigt. Dabei macht es für die Bank keinen Unterschied, ob der Schlüssel per Software erzeugt und auf Diskette gespeichert wird oder ob der Schlüssel in einer RSA-Chipkarte erzeugt und gespeichert wird. Man kann also die Schlüssel in der RSA-Chipkarte erzeugen lassen und erhält so die erhöhte Sicherheit, daß der private Schlüssel nur auf der Chipkarte existiert.