Cardreader auslesen mit CT-API

[Guido R.]

Hallo !
Ich arbeite derzeit an einem Programm, mit dem ich KVKs und eGKs auslesen muss.
Von der Möglichkeit PC/SC verwenden zu können und somit komfortabel auf die Komponenten von Nobbi zurückgreifen zu können habe ich mich a.G. eines früheren Beitrags (http://www.delphipraxis.net/156839-a...els-pc-sc.html) bereits verabschieded und verwende daher die CT-API.

Derzeitiges Testgerät : Cherry 2052MKT+
CT-API : ctpcsc32kv.dll (Ist trotz "pcsc" im Namen lt. Cherry die korrekte CT-API-DLL)

Die 3 Funktionen der CTAPI binde ich dynamisch ein als :

Delphi-Quellcode:

   
  Type
   TFNCT_init     = function(Ctn:Word; PN:Word):ShortInt;StdCall;
   TFNCT_data     = function(Ctn:Word; Dad:Byte; SAD:Byte; Lc:Word; Cmd:Pointer; Lr:Word; Rsp:Pointer):ShortInt;StdCall;
   TFNCT_close    = function(Ctn:Word):ShortInt;StdCall;
  Var
   CT_Init        : TFNCT_Init;
   CT_Data        : TFNCT_Data;
   CT_Close       : TFNCT_Close;

Dies funktioniert soweit auch. Sowohl CT_Init, als auch CT_Close geben 0=OK zurück.
CT_Data bekomme ich aber einfach nicht zum laufen.

Delphi-Quellcode:

function tKVKReader.ResetCT: ShortInt; {Aufruf aus anderer Funktion zwischen CT_Init und CT_Close ; CTN global def.}
Var command: Array of Byte;
    response: Array of Byte;
    DAD,SAD : Byte;
    LenRes, LenCmd : Word;
begin
 SetLength(Command,5);
 command[0]:=$20;
 command[1]:=$11;
 command[2]:=$00;
 command[3]:=$00;
 command[4]:=$00;

 SetLength(Response,256);

 LenRes := Length(Response);
 LenCmd := Length(Command);

 DAD := $01;
 SAD := $02;

 Result := CT_Data(Ctn,DAD,SAD,LenCmd,Pointer(Command),LenRes,Pointer(response));
 end;

Ich erhalte entweder einen Zugriffsfehler in der DLL oder den Rückgabewert -1="Fehlerhafter Parameter oder Wert",je nachdem, ob ich für DAD den Wert "1" oder "0" setze...

Irgendwie trete ich hier auf der Stelle. Hat jmd. Erfahrung mit der CT-API ?

Gruß
Guido R.

[p80286]

Versuch es mal mit Pointer(command[0]), ich meine da war etwas....?
Gruß
K-H

[Guido R.]

Hallo K-H!

Geringfügige Verbesserung der Situation : Mit Deiner Änderung kommt immer -1="Fehlerhafter Parameter oder Wert" heraus. - Der Zugriffsfehler ist damit weg.


Gruß
Guido R.

[Klaus01]

Hallo,

versuche mal Pointer(response[0])

Grüße
Klaus

[p80286]

Zitat:

Zitat von Klaus01 (Beitrag 1105665)

Hallo,

versuche mal Pointer(response[0])

Grüße
Klaus

Meinst Du das ist notwendig?
Gruß
K-H

[Klaus01]

Zitat:

Zitat von p80286 (Beitrag 1105671)

Zitat:

Zitat von Klaus01 (Beitrag 1105665)

Hallo,

versuche mal Pointer(response[0])

Grüße
Klaus

Meinst Du das ist notwendig?
Gruß
K-H

.. ich weiß es nicht, deshalb habe ich auch versuche mal geschrieben.

Klaus

[Guido R.]

Ist es ! - Ohne ist der Zugriffsfehler wieder da !

Gruß
Guido R.

[hoika]

Hallo,

wie ist denn CT_Data definiert

Zitat:

Result := CT_Data(Ctn,DAD,SAD,LenCmd,Pointer(Command),LenRes ,Pointer(response));

Was wäre es mit Result := CT_Data(Ctn,DAD,SAD,LenCmd,@Command[0],LenRes,@response[0]));


Heiko

[Klaus01]

Zitat:

Zitat von hoika (Beitrag 1105722)

Hallo,

wie ist denn CT_Data definiert
Heiko

siehe Post #1

Delphi-Quellcode:

  Type
   TFNCT_init = function(Ctn:Word; PN:Word):ShortInt;StdCall;
   TFNCT_data = function(Ctn:Word; Dad:Byte; SAD:Byte; Lc:Word; Cmd:Pointer; Lr:Word; Rsp:Pointer):ShortInt;StdCall;
   TFNCT_close = function(Ctn:Word):ShortInt;StdCall;
  Var
   CT_Init : TFNCT_Init;
   CT_Data : TFNCT_Data;
   CT_Close : TFNCT_Close;

Grüße
Klaus

[Klaus01]

Laut diesem Link ist für die eGK eine mindest Firmware Version notwendig. Hast Du diese Firmware?

Hier ist ein Beispiel in VB zu finden.

In C sähe die Funktion so aus: typedef char (*CT_DATA) (USHORT, UCHAR*, UCHAR*, USHORT, UCHAR*, USHORT*, CHAR*);
Quelle: Ein QT Forum

Grüße
Klaus

[Guido R.]

An der Firmware kann es (noch) nicht liegen. - Die Zusendung einer eGK durch die Gematik steht noch aus. Daher teste ich derzeit nur an der KVK. Deren Spezifikation sollte inzwischen wohl jedes eHealth-Terminal unterstützen.

Hab zwischendurch auch SAD und DAD als pByte definiert. Gleiches Problem :(

Gruß
Guido R.

[Klaus01]

Code:

typedef 
         char (*CT_DATA) (USHORT, UCHAR*, UCHAR*, USHORT, UCHAR*, USHORT*, CHAR*);

Wenn der Funktionskopf richtig sein sollte (habe leider noch keine offizielles PDF o.ä. mit den Headern gefunden), dann ist die Längenangabe zur Responsezeichenkette auch ein Pointer.
Die Längenangabe zur Befehlszeichenkette jedoch nicht.

Grüße
Klaus

[Guido R.]

Gem. Richtlinien der Teletrust ist der Aufbau der CT_Data wie folgt :

CTN IU16
DAD IU8
SAD IU8
LENC IU16
COMMAND Referenzadresse eines Feldes mit Elementen vom Typ IU8
LENR IU16
RESPONSE Referenzadresse eines Feldes mit Elementen vom Typ IU8

RESULT IS8

(IS8=Integer Signed 8Bit, IU8=Integer Unsigned 8Bit, IU16=Integer Unsigned 16Bit)

Quelle : http://www.teletrust.de/uploads/media/MKT1-0_T3.pdf

[Guido R.]

GESCHAFFT !:thumb:

Kurz gesagt : Die Definition der CT-API nach Teletrust ist falsch (oder zumindest sehr unklar definiert).
LENR (s. vorherigen Beitrag) MUSS ein Pointer auf eine Word-Variable sein, da CT_Data in diesen Wert die eigentliche Länge der Antwort schreibt.

Somit ist eine funktionierende Definition für CT_Data wie folgt:

Delphi-Quellcode:

function(Ctn:Word; Dad:PByte; SAD:PByte; Lc:Word; Cmd:Pointer; Lr:Pointer; Rsp:Pointer):ShortInt;StdCall;

Gruß
Guido R.

[Wulfhorst]

Ich bin als Psychotherapeut neuerdings gezwungen die Gesundheitskarte - eGK - auszulesen. Bislang habe ich die KVK-Karte immer mit einem ganz alten Programm aus der TOOLBOX auslesen können. Das kleine Programm hat mit einer - leider - kompilierten Komponente von TOWITOKO gearbeitet. Aber es lies sich prima in meine Delphi 4.01 Projekte integrieren. Zertifiziere Programme können selbstverständlich mittlerweile die eGK auslesen. Aber ich arbeite parallel und alltags immer noch mit meinem eigenen Programm (www.wulfhorst.info -> EMILA)und möchte das auch weiterhin tun. Gibt es Hilfe? Ich könnte mir auch eine kleine separate App vorstellen, die den Inhalt der eGK als ASCII bzw. ini-Datei ausgibt, die ich dann mit meinen großen Programm auslese. Ob Quelltext (wunderbar!) oder als kleines kompiliertes Zusatzprogramm mit obiger Exportfunktion. Beides würde einem alten Dephi-Freak das Leben leichter machen. Danke.

[bernau]

Ich muss den Thread auch noch mal nach vorne holen. Muss (Adress-)daten aus der eGK lesen. Ein direkter zugriff auf eine API über eine Delphi-Komponente wäre natürlich schön, mir würde aber auch ein externes Programm reichen, welches diese Daten einfach in eine Textdatei schreibt, welche ich dann auslesen kann. Kennt jemand so ein Programm?

[jobo]

Soweit ich weiß sind die Daten der eGK in verschiedenen Containern in meheren Stufen abgesichert/ verschlüsselt. Zur Infrastruktur und Karte gibt es aber tonnenweise Doku, insofern könnte man es sicher hinbekommen (Uugangsberechtigung vorausgesetzt).
Wenn man tonnenweise Doku in Code umrechnet, ist das Programm aber wahrscheinlich nicht mehr so klein, wie früher.

[Assarbad]

Zitat:

Zitat von Guido R. (Beitrag 1106496)

GESCHAFFT !:thumb:

Kurz gesagt : Die Definition der CT-API nach Teletrust ist falsch (oder zumindest sehr unklar definiert).

Warum? Klaus hatte doch den Prototypen geliefert:

Ich korrigiere mal den Lapsus mit der Aufrufkonvention:

Code:

char (*__stdcall CT_DATA) (USHORT, UCHAR*, UCHAR*, USHORT, UCHAR*, USHORT*, CHAR*);

Jetzt deine Version:

Delphi-Quellcode:

function(Ctn:Word; Dad:PByte; SAD:PByte; Lc:Word; Cmd:Pointer; Lr:Pointer; Rsp:Pointer):ShortInt;StdCall;

... und jetzt meine etwas mehr delphianisierte Version:

Delphi-Quellcode:

TFNCData = function(ctn: Word; var dad: Byte; var sad: Byte; lenc: Word; command: ^Byte; var lenr: Word; response: ^Byte): Byte; stdcall;

Bei "dad" und "sad" scheint es sich ja nur um einen einzelnen 8bit-Wert zu handeln, während mit "response" und "command" jeweils ein array gemeint ist. Ich nehme mal an jemand der hier in den letzten Jahren Delphi benutzt hat kann das noch verfeinern (bspw. einen passenderen Typen als ^Byte).

Man merkt gleich daß das aus deutschen Landen kommt ... :? ... man könnte ja mindestens mal die C-Prototypen in den PDFs angeben oder am besten gleich einen normalen Header. Grausam sowas ...