FinTS-3.0 und iTAN in HBCI4Java

Hallo,

der HBCI4Java-Test-Server spricht jetzt auch FinTS-3 und unterstützt
das neue Zweischritt-Verfahren, welches die Basis für iTAN
darstellt (http://hbci4java.kapott.org/demoserver.html).

Wer das neue Protokoll und/oder iTAN testen will, benötigt
einen FinTS- und/oder iTAN-fähigen Client sowie einen Zugang für
den HBCI4Java-Test-Server. Neben evtl. kommerziell verfügbarer
Client-Software kann auch einfach wallstreet9 (Download unter
http://hbci4java.kapott.org/#download) verwendet werden.

wallstreet9 selbst musste dafür nicht angepasst werden, wohl aber
die darunterliegende HBCI4Java-Client-Bibliothek. Es kann also die
"alte" wallstreet9-Version verwendet werden - alle notwendigen
Änderungen für die Unterstützung von FinTS-3 und iTAN sind für die
Client-Applikation völlig transparent in den neuen HBCI4Java-Archiven
verborgen (http://hbci4java.kapott.org/#download).


Folgende Details zur FinTS-Unterstützung:

- es wird das FinTS-3-Protokoll unterstützt (auf Basis der
Spezifikation vom 21.06.2005).

- es wird das Sicherheitsverfahren RDH-1 unterstützt

- Das DDV-Verfahren wurde noch nicht getestet - wenn sich die
entsprechende Spezifikation im Vergleich zu HBCI-2.2 nicht ge-
ändert hat, dann wird auch DDV unterstützt.

- es wird das Sicherheitsverfahren PIN/TAN unterstützt

- für PIN/TAN wird das "normale" Einschritt-Verfahren unterstützt

- außerdem wird für PIN/TAN das Zweischrittverfahren unterstützt,
welches die Basis für iTAN (indizierte TAN) darstellt.

- Beim PIN/TAN-Zweischritt-Verfahren werden sowohl die Prozess-
Variante #1 als auch Variante #2 unterstützt.
(PV#1: erst Einreichen eines Auftrags-Hashes, dann Einreichen des
eigentlichen Auftrages zusammen mit der TAN;
PV#2: Einreichen des Auftrages, danach wird die TAN "nachgereicht"
für beide PV gilt: die TAN muss vom Anwender aus einer Challenge
ermittelt werden, die nach dem jeweils ersten Schritt vom Server
zurückgegeben wird).

Diese neue Zweischritt-Folge ist für den Entwickler von HBCI-
Client-Software völlig transparent - es müssen weiterhin nur
Aufträge
- erzeugt (job=handle.newJob("DauerEdit"); job.setParam(...)),
- in eine Queue gestellt (handle.addJob(job))
- und schließlich ausgeführt (handle.execute())
werden.
Ist für den aktuellen Dialog ein Zweischritt-Verfahren aktiv, dann
erkennt HBCI4Java selbst, ob TAN-pflichtige Aufträge existieren
und dass das Einreichen dieser Aufträge im Zweischritt-Verfahren
erfolgen muss.


Natürlich sind auch noch eine ganze Reihe Details nicht fertig
oder noch gar nicht implementiert:

- für das Zweischritt-Verfahren ist die Prozessvariante #1 zwar
implementiert, allerdings ist der "errechnete" Hashwert für
einen Auftrag im Moment immer der String "ORDERHASH" (das liegt
an einem noch ungeklärten Problem mit der Spezifikation)
[gilt für Client- und Server-Code]

- beim Zweischritt-Verfahren wird die Auswahl einer TAN-Liste
aus einer Menge von mehreren Listen nicht unterstützt
[Client und Server]

- beim Zweischritt-Verfahren werden keine Mehrfachsignaturen
unterstützt; auch das zeitversetzte Senden des ersten und zweiten
Schrittes (dialog-übergreifend) dürfte zumindest client-seitig
noch nicht funktionieren.
[Client und Server]

- beim Zweischritt-Verfahren werden die optionalen Bankensignaturen
für HITAN-Segmente nicht unterstützt
[Client und Server]

- es werden einige eigentlich notwendige Konsistenz-Checks noch nicht
durchgeführt, das heisst es werden sowohl vom Client- als auch
vom Server-Code u.U. Nachrichten bzw. Daten akzeptiert, die
eigentlich nicht möglich sind und abgewiesen werden sollten.
[Client und Server]

- von den RDH-Verfahren wird im Moment nur RDH-1 unterstützt -
demzufolge gibt es auch noch keine Logik für die richtige
Verwendung von Sicherheitsklassen.
[Client und Server]

- verschiedene neue FinTS-Features (wie z.B. die LifeIndikator-
Nachricht oder die Kompression von Nachrichten, Zertifikate) werden
noch nicht unterstützt
[Client und Server]

- der Server "vergisst" bei einem Neustart im Moment Daten des
Zweischritt-Verfahrens - wird also zwischen dem ersten und dem
zweiten Schritt des Zweischritt-Verfahrens der Server neu ge-
startet, dann kann der zweite Schritt nicht erfolgreich ausge-
führt werden.
[Server]

- es gibt noch ein paar Stellen, an denen der Server angelegte Daten-
strukturen auch mal wieder aufräumen sollte - im Moment wachsen
diverse Tabellen einfach unendlich weiter.
[Server]

- die Rückgabecodes, die bei Verwendung des Zweischritt-Verfahrens
zurückgegeben werden, entsprechen noch nicht der Spezifikation.
[Server]


Alle diese Punkte stehen schon auf der TODO-Liste
Einige Features (z.B. zeitversetzte Mehrfachsignaturen beim
Zweischritt-Verfahren) sind dabei allerdings wesentlich
aufwändiger zu implementieren als andere (z.B. die fehlenden
RDH-Verfahren).


Da ich im Moment weder einen zweischrittfähigen Client noch einen
Server, der das Zweischritt-Verfahren beherrscht, auftreiben konnte,
ist dieser Code noch nicht besonders gut getestet, da ich nur "gegen
mich selbst" testen kann und die versandten Nachrichten manuell
mit der Spezifikation vergleichen kann.

Wer also einen Client oder Server eines Drittanbieters kennt,
der FinTS (und evtl. sogar das Zweischritt-Verfahren) beherrscht, ist
herzlichst zum Testen und Schreiben von Bugreports eingeladen


Viele Grüße
-Stefan-

hallo,

danke für den hinweis, das werd ich wohl mal versuchen.

-stefan-

Muss ich dafuer in HBCICallback#callback irgendwas zusaetzlich beachten? Weil:

- mir ist HBCICallback.NEED_PT_SECMECH aufgefallen
- bei iTAN muesste doch der Server die Nummer der einzugebenden TAN uebermitteln. Ich nehme mal an, diese Nummer kriege ich ueber einen Callback-Aufruf, oder?

Gruss
Olaf

Ich denke hier steht drin wie mit dem Hash umzugehen ist:

http://www.hbci-zka.de/dokumen…-06-21.pdf

Befunde klingt gut, fast so als wären die Zweischrittverfahren erkrankt
*hust*