VRNW 1.30

Gestern habe ich bei einem Kunden die VRNW Vers. 1.30 neu installiert und wollte die VRNW-Card syncronisieren - leider erfolglos. VRNW hat sich komplett aufgehängt und lies sich nur über den Taskmanager schließen.

(Systemumgebung: Win 98 SE, TDSL, Reiner SCT USB)

Bei einer erneuten Syncronisation kam die Meldung:
"(9320) Signatur noch nicht freigeschaltet oder nicht hinterlegt"

Lösung: VRNW hat den Kartenstatus verändert. Dadurch ist eine erneute Syscronisation nicht mehr möglich - die Karte ist jetzt unbrauchbar! (*)

Bei Neuauslieferung ist der Status: "Weder alter noch aktueller Schluessel liegt der Bank vor"
Nach erfolgreicher Syscronisation ist der Status: "Aktueller Schluessel liegt der Bank vor"

(*) Mit Hilfe eines kleinen Softwaretools kann man den Status wieder auf den Auslieferungszustand zurücksetzen. Die Quelle darf ich allerdings noch nicht nennen - ich schätze jedoch, dass dieses Tool demnächst allen Fachberatern zur Verfügung steht.

Hier die Antwort zu dem Problem aus München:

pro Bankverbindung ist auf der Chipkarte ein Schlüsselstatus gespeichert.

06 = Schlüssel muss noch eingericht werden (Auslieferungszustand, löst eine Ersteinreichung der Schlüssel durch den Kernel aus))
10 = Schlüssel wurde eingereicht (Zustand nach Ersteinreichung der Schlüssel, der Kernel nutzt den Schlüssel direkt)

Auf der Chipkarte ist das Zertifikat, das bei der Ersteinreichung der Schlüssel mitgesendet wird, in einem 1500 byte grossen Feld gespeichert.
Das Zertifikat hat eine variable Länge, dieses Feld ist mit x'FF...' aufgefüllt.

Der bisherige 'Starfinanz-Kernel' hat bei diesem Zertifikat vor der Einreichung die x'FF...' abgeschnitten. Dieses Zertifikat wurde vom 'GAD-Konverter' richtig erkannt und verarbeitet. Die eingereichten Kundenschlüssel wurden bei uns gespeichert, eine Antwortnachricht (Einreichung der Schlüssel ist ok) an den Client gesendet und vom Kundenprodukt daraufhin der Schlüsselstatus auf '10' gesetzt.

Der neue 'PPI-Kernel', bei uns ab der Version 1.30 eingesetzt, kürzt das Zertifikat nicht, sondern sendet 1500 byte (Zertifikat + x'FF...') an den HOST.
Das Zertifikat wird so vom 'GAD-Konverter' nicht richtig erkannt, es kommt zu einem Programmabbruch. Der Kunde erhält auf seine Schlüsseleinreichung keine Antwort mehr. Nach einem timeout wird der Verbindungsversuch abgebrochen.

Leider wird der Schlüsselstatus vom 'PPI-Kernel' bereits vor diesem Abbruch auf '10' gesetzt, so dass auf der Chipkarte fälschlicherweise der Schlüsselstatus auf '10' gesetzt bleibt, obwohl keine erfolgreiche Schlüsseleinreichung stattgefunden hat.

Bei der nächsten Nutzung der Chipkarte wird der Schlüsselstatus '10' vorgefunden und die Kundenschlüssel vom Kernel direkt benutzt. Am HOST sind diese Schlüssel aber noch nicht eingereicht, der Vorgang wird abgelehnt (.. noch nicht freigeschaltet).

Temporäre Lösung:

1. Mit dem von uns entwickelten Tool den Schlüsselstatus von '10' auf '06' zurücksetzen
2. Ersteinreichung mit einer VRNetWorld Sogtware Version < 1.30 durchführen.

Danach kann die Chipkarte problemlos mit der Version 1.30 genutzt werden.

Bei der GAD äußert sich das Problem bei der Erstsynchronisation mit der beliebten Fehlermeldung "System z. Zt. nicht verfügbar" :banghead:

Mit dieser Fehlermeldung hab ich mich bis vorhin auch rumgeärgert!
Abhilfe: T-Online Software installiert, Karte damit aktiviert (oder synchronisiert
oder wie auch immer) und prompt mochte auch die VR-Networld-Software meine
Karte.

Alex.