Berliner Volksbank / Fiducia mit FinTS 3.0 und RDH-10

Hallo,

bei der Suche nach einem Homebanking-Programm für mein Konto bei der Berliner Volksbank bin ich auf Hibiscus gestoßen.
Nun habe ich vor ein paar Tagen einen Brief erhalten, in dem die Umstellung auf FinTS 3.0 mit RDH-10 angekündigt wird, die Verwendung von RDH-2 ist ab dem 15.09.2009 nicht mehr möglich.

Der von Hibiscus generierte Hash-Wert stimmt jedoch immer mit dem RDH-2-Hashwert überein. Ist RDH-10 mit Hibiscus bzw. HBCI4Java nicht möglich?

Folgendes Posting von kleiner77 hört sich fast danach an:
Hashwert von Bank und Hibiscus stimmen nicht überein

Wenn das so ist: Gibt es schon Pläne, RDH-10 zu integrieren? Laut Hotline betrifft das alle Fiducia-Banken. Die Umstellung wurde auf Empfehlung des Bundesamts für Sicherheit in der Informationstechnik veranlasst.

Danke & Grüße

sw

Hallo,

das oben geschilderte Problem tritt mit einem neuen ini-Brief auf. Auf dem ini-Brief stehen zwei Hash-Werte: einmal für RDH-2 (nur gültig bis 15.09.09) und einmal für RDH-10. Hibiscus erstellt jedoch immer einen Schlüssel mit dem RDH-2-Hashwert.

Grüße

sw

habe den aktuellen SVN-Snapshot gerade nach Hibiscus ubernommen. Siehe http://www.onlinebanking-forum…9216#59216

Mutige vor

Kann mir jemand mal erklären was ich genau auswählen muss? Ich hab Hibiscus gerade neu installiert aber ich habe hier nur HBCI4/Java und RDH2 zur Wahl wenn ich ein neues Sicherheitsmedium einrichten will und irgendwie scheint beides nicht zu funktionieren. Der Hash den Hibiscus generiert funktioniert bei meiner Bank (Raiba) nicht.

Gruß, Dave

Das hatte ich so probiert... Hat nicht funktioniert... Dumm, dann werde ich wohl oder übel doch dieses VR-Networld benutzen müssen...

Ärgerlich...

Gerade bei den VR-Banken funktioniert FinTS-3 mit RDH-10 eigentlich vorbildlich. Kannst Du konkretere Aussagen machen als "funktioniert nicht"? Vielleicht eine Fehlermeldung oder ein Logfile?

-stefan-

HBCI4Java-intern heisst das Dateiformat "RDH2File". Im Prinzip müsste es auch ein "RDH10File" geben. Da beide Dateiformate aber sehr änlich sind, kann die "RDH2File"-Implementierung auch RDH-10-Dateien lesen und schreiben.

Werde mal ein, zwei Wrapper-Klassen bauen, damit man mit diesen Bezeichnungen nicht mehr so durcheinander kommt

-stefan-

Nicht wirklich. Falls beim Erzeugen der Schlüssel keine Fehler aufgetreten sind, und falls der ausgedruckte INI-Brief am Ende plausibel aussieht (richtige User-ID, richtige HBCI-Version ("FinTS-3" bzw. "300"), Schlüsselnummer=10, 32 Bytes Hash-Wert), sollte eigentlich alles i.O. sein - zumindest war das bei allen anderen mir bekannten VR-Kunden bis jetzt so

Im Zweifelsfall richtest Du den Schlüssel aber tatsächlich mit VR-Networld ein - die entstehende Schlüsseldatei ist eine solche "RDH-2/10-Datei", die Du parallel sowohl mit VR-Networld als auch HBCI4Java nutzen kannst.

-stefan-

Hallo Dave,
noch ein Gedanke. Als ich meinen INI Brief einreichte, sagte die Mitarbeitein der Bank, dass der Hashwert nicht stimmte. Wir haben dann telefonisch abgeklaert, wo die
Differenzen herkamen. Es waren nur einige wenige Werte falsch abgelesen
worden. Anscheinend ist da noch Handarbeit im Spiel.
Meine Raiba Bank hat die URL hbci01.fiducia.de (Süddeutscher Raum).
Gruss Guenter

Ein bisschen seltsam ist das ganze schon. Wenn alle anderen Daten plausibel sind (siehe oben), und nur der Hash die falschen "Zahlen" aufweist, würde das auf einen Rechenfehler in HBCI4Java beim Berechnen des Schlüssel-Hashs hindeuten.

Das jedoch halte ich für eher unwahrscheinlich, da bis dato ja schon eine ganze Menge Nutzer erfolgreich ihre RDH-10-Schlüssel neu bei der Bank eingereicht haben (will aber nicht ausschließen, dass Dein Schlüssel evtl. irgendeinen "Grenzfall" bei der Berechnung trifft, der tatsächlich schiefgeht).

Wenn ich mich nicht irre, habe ich mal von einem Problem gehört, das darin bestand, dass eine Bank für die Berechnung des RDH-10-Hashwertes den falschen Algorithmus verwendet (nämlich den für RDH-2-Schlüssel) - in dem Fall kann der Hashwert-Vergleich nicht gutgehen. Das würde aber auch bedeuten, dass die Bank einen 20-stelligen Hashwert erwartet anstatt eines 32-stelligen - und das hatten wir ja oben schon ausgeschlossen, richtig?

Etwas ratlos...
-stefan-