Re: [Hbci4java-help] RDH - Probleme mit dem Demo

[Stefan P. <kle...@gm...>]

Hallo,

> Nachdem ich seit meiner letzten Frage aus Zeitgr=FCnden nichts mit HBCI4J=
ava=20
> machen konnte, habe ich mir mittlerweile die 2.1 heruntergeladen. In der =
Demo=20
> kann man ja nun keinen Schl=FCssel mehr erzeugen, wenn ich das richtig se=
he.=20

langsam sehe ich das (Verst=E4ndigungs-) Problem. Also das wichtigste
zuerst: HBCI4Java sollte auf gar keinen Fall mit schon existierenden
Schl=FCsseldateien anderer Software gef=FCttert werden! HBCI4Java kann dies=
e
(noch) nicht lesen, =FCberschreibt diese aber (hoffentlich) auch nicht.

So wie ich das verstanden habe, wollen Sie Ihre schon existierenden
RSA-Schl=FCssel irgendwie in HBCI4Java "importieren". Das ist zur Zeit=20
leider =FCberhaupt nicht m=F6glich (bitte auf Release 2.2 warten).

Der prinzipielle interne Ablauf ist folgender: Beim Initialisieren
eines Passports mit HBCIPassport.getInstance("RDH") wird eine Passport-
Datei (=3D"Schl=FCsseldatei") geladen. Existiert diese noch nicht,
so werden einige ben=F6tigte Daten (User-ID, BLZ, Host-Adresse)
via Callback-Mechanismus abgefragt, und die Datei wird mit diesen
Daten erzeugt.

Beim Initialisieren eines HBCIHandlers mit new HBCIHandler(...) wird
u.a. =FCberpr=FCft, ob das Passport bereit Schl=FCssel enth=E4lt. Ist das
nicht der Fall, so werden neue Schl=FCssel erzeugt und in der
Schl=FCsseldatei gepspeichert.

Dieser Vorgang wird von HBCI4Java v=F6llig autonom ausgef=FChrt, d.h. es
gibt keine Notwendigkeit und auch keine M=F6glichkeit, selbst das Erzeugen
neuer RSA-Schl=FCssel zu veranlassen. Zur Zeit gibt es auch noch keine
Methode, schon existierende RSA-Schl=FCssel zu "importieren".=20

> F=FCr die Schl=FCsselerzeugung habe ich nun die HBCIPassportRDH.getKeyDat=
a als=20
> zust=E4ndige Methode ausgemacht. Ich hoffe, da=DF das schon einmal korrek=
t ist.=20

Die Methode HBCIPassportRDH.getKeyData() hat genau den umgekehrten
Sinn: damit werden Schl=FCsseldaten der RSA-Schl=FCssel zur=FCckge-
geben, die HBCI4Java verwendet (d.h. selbst erzeugt und in der=20
Schl=FCsseldatei gespeichert hat). Diese Methode ist auch nicht besonders
"gelungen", weil es sinnvoller w=E4re, diese Schl=FCsseldaten in der JCE-
typischen Form als KeySpec zur=FCckzugeben...

> :-) Diese braucht ja nun einen HBCIKey. Dazu habe ich nun einige Fragen:

wie gesagt - das stimmt zwar im Prinzip, aber es gibt noch keine=20
M=F6glichkeit, einen "von Hand erzeugten" HBCIKey an HBCI4Java zu=20
=FCbergeben. Ab Release 2.2 wird das m=F6glich sein, wahrscheinlich aber
nicht =FCber den "Umweg" mit dem HBCIKey...

> Was mach ich mit den Eigenschaften "key" und "num"?
> "userid" ist sicher die Benutzer-Id auf dem Brief von meiner Bank, oder?
> Ist "version" die HBCI-Version - in meinem Fall 2.1?

(obwohl das dann ja eigentlich hinf=E4llig ist, hier trotzdem die
 Erkl=E4rungen: "key" enth=E4lt die eigentlichen Schl=FCsseldaten, also
 das kryptographische Material. Im Falle von RSA gibt es intern
 sechs HBCIKey-Instanzen pro Passport: jeweils eine f=FCr den
 =F6ffentlichen Signier(#1)- und Chiffrier(#2)-Schl=FCssel der Bank,
 jeweils einen =F6ffentlichen Signiert(#3)- und Chiffrier(#4)-Schl=FCssel
 des Nutzers und jeweils einen privaten Signier(#5)- und Chiffrier(#6)-
 Schl=FCssel des Nutzers.

 "num" und "version" dienen der Identifikation des Schl=FCssel. Ein Nutzer
 (und auch die Bank) kann zu jedem beliebigen Zeitpunkt neue Signier-
 und Chiffrierschl=FCssel erzeugen. Um bei der Kommunikation=20
 klarzustellen, welcher Schl=FCssel jeweils verwendet wurde, werden
 diese Informationen (num und version) in die HBCI-Nachrichten=20
 aufgenommen, damit der Komm.-partner wei=DF, mit welchen Schl=FCsseln
 er wiederum die Nachricht entschl=FCsseln bzw. die Signatur =FCberpr=FCfen
 soll. Beide Werte werden von HBCI4Java selbst verwaltet.

 und ja, userid ist manchmal die userid aus dem INI-Brief und manchmal
 eine bankinterne User-ID (je nachdem, um wessen Schl=FCssel es sich
 handelt). Auch dieser Wert wird von HBCI4Java intern verwaltet und
 hat nach au=DFen hin keine sinnvolle Bedeutung.)

> Sorry f=FCr die dummen Fragen, aber ich habe Angst, mir meine Schl=FCssel=
datei zu=20
> zerschiessen. :-)

es gibt keine dummen Fragen, nur dumme Anworten... - und schlechte
Dokumentation ;-)

Um Ihre schon existierenden RSA-Schl=FCssel importieren zu k=F6nnen, m=FCss=
ten
Sie die Schl=FCsseldaten kennen (also sowohl vom Signier- als=20
auch vom Chiffrierschl=FCssel jeweils den =F6ffentlichen und den privaten
Exponenten sowie den Modulus). Diese Daten k=F6nnen Sie ab HBCI4Java 2.2
zum "Import" ihrer existierenden Schl=FCssel benutzen.

Alternativ dazu w=E4re es sehr hilfreich, wenn ich das Dateiformat der
von Ihnen verwendeten Schl=FCsseldatei kennen w=FCrden, da es sich aber
scheinbar um ein propriet=E4res Format handelt, sehe ich da wenig
Chancen, Informationen zu bekommen.

Eine dritte (und etwas mutigere) Alternative w=E4re, wenn Sie Ihre=20
RSA-Schl=FCssel =FCber das Web-Interface Ihrer Bank sperren w=FCrden.
Dann k=F6nnten Sie mit HBCI4Java komplett neue Schl=FCssel generieren,
m=FCssten aber auch einen neuen INI-Brief erzeugen und diesen zur
Verifikation an die Bank senden.

Gr=FC=DFe
-Stefan-

--=20
--------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

Key fingerprint =3D 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
--------------------------------------------------------------------