Hallo,

ich habe folgendes Problem:

Kunde hat auf EBICS umgestellt, mehrere User mit A-Berechtigungen und einen T-User.
Die Zahlungen werden in Sfirm 2.2.1 von 2 A-Berechtigen unterschrieben und dann von dem hinterlegten technischen User gesendet. Das funktioniert auch. Angemeldet sehe ich einen A-User.

In der EBICS Verwaltung ist hinterlegt/Häkchen "automatische Protokollabholung bei EU-Übertragung nach ca. 1 Minute" .
--> Es tut sich aber nichts. :roll:

Manuell kann ich die PTK dann mit dem angemeldeten User abholen, der muss dann sein Sicherheitsmedium einlegen + Kennwort eingeben; geht das nicht automatisch wie in der EBICS Verwaltung angekreuzt ist mit dem technischen User?!

Kennt sich da jemand von den Sparkässlern aus? Bestimmt doch ))

Danke

diddidalle

Hallo,

Frage mal:
Die beiden A-Unterschriften werden geleistet und dann zusammen mit der Datei versendet? Das heisst es findet kein zweitverzögerter Versand der EU statt?

In diesem Fall wird IMHO der technische User nicht benutzt! Es sendet der angemeldete User, der auch die Unterschrift (hier A) leistet.

Den T-User nutzt man, um zeitverzögerte Aufträge automatisch senden zu können, da nur bei diesem eine Speicherung der Kennwörter erlaubt ist.

Ist aber ein User anwesend, der auch unterschreibt, ist der Versand per technischem User überflüssig und dürfte durch die Programmlogik eliminiert werden.

Ob das so ist, geht aus dem EBICS-Protokoll hervor. Taucht dort die User-ID des T-User nicht als Sender auf, wurde er auch nicht benutzt

Trotzdem sollte die automatische PTK-Abholung funzen (Auftrag vom angemeldeten A-User). Wird denn ein Auftrag dazu erstellt?

Also der Fehler ist jetzt lokalisiert, es liegt wohl an der Schlüssellänge von SFIRM mit 2048 Bit. Unser Server verschlüsselt nur mit 1024 Bit.

Neue Frage: Gibt es die Möglichkeit in SFIRM nur mit 1024 Bit zu verschlüsseln?

Hallo diddidalle,

erzähl mal genauer was du konkret mit Schlüssellänge meinst.
Es gibt für EBICS drei Schlüsselpaare, eines ist per Spezifikation auf 1024 bit festgenagelt (EU), die anderen beiden darf das Softwareprodukt im eigenen Ermessen zwischen 1024 und 16536bit festlegen und der Bankrechner hat das so zu fressen (Sepzifikation eben) ...
In der Erprobungsphase gab es mit einer grünen Bank an der Stelle mal ein Problem, aber das war eine Testumgebung und ist -bankseitig- bereinigt worden.

Oder meinst du etwas anderes?

Also der O-Ton: Bei der Entschlüsselung des Sessionnkeys tritt ein Fehler bzgl. des Paddings nach PKCS #1 (RSA Cryptographie Standard) auf. Der Sessionkey vom Server wird mit einem 1024 Bit Schlüssel (E001) verschlüsselt, während der Authentifikations-/Verschlüsselungsschlüssel in Sfirm32 eine Schlüssellänge von 2048 Bit hat.

Der EBICS Authentifikationsschlüssel der bei uns hinterlegt ist, hat eine Länge von 1024 Bit (E001).