Hallo Experten,
seit Tagen versuche ich nun, eine Java-Anwendung zum Auslesen /
Beschreiben einer Smartcard zu schreiben.
Den Kartenleser kann ich problemlos ansprechen, doch egal, welchen APDU
ich zur Karte sende - es kommt immer die Antwort "6E00" zurück (falsches
CLA byte).
Die Karte ist eine I2C-Karte, der Kartenleser unterstützt dies auch
(Protokoll S=8). Das Protokoll S=8 ist in Java (javax.smartcardio) aber
gar nicht verfügbar, also nehme ich T=0. Ist das der Fehler?
Die Karte erwartet ja meines Wissens einen START-Befehl. Aber wie setze
ich den? Macht der Kartenleser das automatisch?
Ich will doch nur etwas auf diese Karte schreiben!! :-(
Das einbinden der mit dem Cardreader mitgelieferten DLL hat leider gar
nicht geklappt.
Im Internet findet man zwar viele mit ähnlichen Problemen, aber keine
Lösungen :-(
Wenn jemand auch nur den geringsten Ansatz zur Lösung hat - bitte
melden! Bin für jede Hilfe dankbar, da ich echt am verzweifeln bin...
Gruß
Also I2C ist im SmartCardbereich eigentlich nur die Kommunikation zu
nackten EEPROMs, also kein T=0 oder T=1. Du kannst dir das einfach als
24C08 im Chipcardform vorstellen. Du kannst die Karten auch mit jedem
I2C-Interface ansprechen- Kontakiermöglichkeit vorausgesetzt.
Das ist keine klassische SmartCard wie Telefonkarte, Geldkarte, PKI-Card
etc. Ich vermute mal, da ist dein Denkfehler.
Andy P.
Eine Smartcard kann nicht nur eine (EE)PROM-Karte sein (wie die
Krankenversicherungskarte), sondern auch eine Prozessorkarte sein, z.B.
die sog. ec-Karte, Geldkarte oder Kreditkarten.
Jede Karte jenseits eines EEproms wird nicht mehr via I2C sondern mit
T=0 oder T=1 etc angesprochen. Entweder der TS hat eine I2C Karte oder
er hat eine Karte mit Intelligenz. Beides zusammen geht nicht (mal von
selbstgebauten PIC-Cards etc abgesehen mit ihrer Doppelbeschaltung).
Hier liegt wohl der Fehler, oder der TS hat sich in den Begriffen
vertan.
Andy P.
Hey,
danke für die Antworten - leider werde ich nicht ganz schlau draus.
Das hier ist die Karte, die ich habe:
http://tinyurl.com/3ancmzg
Wie spreche ich die den korrekt an?? :-(
Hi,
also - neue Karte, neuer Versuch.
Diesmal eine SLE 5542, ohne I²C, dafür (hoffentlich) mit Intelligenz.
Hat es schon jemand geschafft, diese Karte zu beschreiben?
Bekomme nach senden des Apdu's "FF B0 ..." leider den Fehler 6981
("Kommando inkompatibel zur Dateistruktur").
BITTE was mache ich denn falsch!? :-(
Das Datenblatt zur Karte ist alles andere als hilfreich :-/
> Das hier ist die Karte, die ich habe:> http://tinyurl.com/3ancmzg
Das ist eine klassische EEPROM-Karte, also nur Speicher ohne Prozessor,
die Kontakte kann man direkt mit I2C ansprechen.
hallo stephan,
danke für deine Antwort.
Das mit dem I2C hat leider nicht geklappt, daher habe ich jetzt eine
andere Karte ( http://tinyurl.com/39chsns ).
Die Befehle sende ich direkt per javax.smartcardio als APDU.
Es kommen die tollsten Fehler, hauptsächlich 6981, 6982, 6a82, 6a86.
Mal passt also die Struktur der Karte nicht, mal fehlt der PIN (wie
übermittle ich den denn an die Karte!?), und mal stimmen die Parameter
nicht.
Und nirgendwo steht, was richtig wäre!
Irgendjemand muss doch schon mal so ne Karte zum laufen gebracht
bekommen haben :-(
Na, hier ist einiges Durcheinander bei Dir:
Bei der gezeigten Karte handelt es sich nicht um eine Smartcard, sondern
um eine Speicherkarte oder, wie schon jemand schrieb, ein EEPROM im
Kartenformat.
Hier gibts weder T=0 oder T=1, das sind alles asynchrone Protokolle, Du
brauchst ein synchrones Protokoll, ob das nun S=8 heißt, weiß ich grad
nicht.
Die Schnittstelle zur Karte ist häufig i2C, es gibt jedoch auch 2-Draht-
und 3-Draht-Interfaces.
Sofern Dein Kartenleser die Karte unterstützt, greift er automatisch mit
dem richtigen Protokoll und dem richtigen Interface darauf zu. Beim
Stecken der Karte und anschließendem Kartenreset wählt er nämlich anhand
des empfangenen ATR (Answer to Reset) der Karte das richtige Protokoll.
Zum PC hin jedoch merkst Du davon nichts, Du kannst allenfalls an der
Antwort auf ResetICC unterscheiden, ob Du eine synchrone Speicherkarte
(90 00) oder eine asynchrone Prozessorkarte (90 01) gesteckt hast. Das
Kartenterminal jedoch spricht immer T=1 zum PC, egal was für eine Karte
gesteckt ist.
Wenn Du also Deine gezeigte blaue Karte gesteckt hast, aktiviere Sie mit
dem Kommando 0x20 0x11 0x01 0x00 an DAD 0x01. Du erhältst dann 0x90 0x00
zurück, die Karte ist eine synchrone Speicherkarte und aktiviert.
Jetzt mal mit 0x00 0xB0 0x00 0x00 0x00 an DAD 0x00 ein ReadBinary an die
Karte schicken, dann sollten 256Bytes + 2 byte Returncode zurückkommen,
z.B.
00 b0 00 00 00
82 13 10 91 .... 90 00
Für tieferen Einstieg mußt Du schauen, die ISO-7816-3 und -4 zu
bekommen...
Gruß...Maschinist
hallo maschinist!
Danke für deine Antwort. Ich stand / stehe kurz vor dem Aufgeben...
Aber du scheinst Ahnung davon zu haben :-)
Speicherkarte, EEPROM, Prozessorkarte - was davon kommt den nun mit
APDU's zurecht? Und was hab ich jetzt eigentlich? -.-
Wie schicke ich denn das 0x20 0x11 0x01 0x00 zur Karte? Und wie an DAD
(=Datenadresse??) 0x01?
Wenn ichs als APDU schicke, kommt 6e00 (CLA Error) zurück, und ne andere
Möglichkeit ist mir nicht bekannt... :-/
Danke und Gruß
Hallo smartcard,
Du redest doch ausschließlich mit dem Kartenleser, der versteht
natürlich APDUs, die ihm gesendet werden, sofern sie korrekt aufgebaut
sind:
Für seine eigene Befehle, also die er selbst ausführen kann, brauchst Du
CLA=0x20 und mußt an DAD (destination adress) 1 senden.
Kartenbefehle werden jedoch mit CLA=0x00 an DAD 0 gesendet. Der
Kartenleser sieht an der DAD, daß es ein Befehl zur Karte ist und
schickt ihn mit dem richtigen Protokoll an die Karte weiter, sodaß Du
Dich, wie geschrieben, nicht um das tatsächliche Kartenprotokoll kümmern
brauchst.
Schreib doch mal etwas mehr zu Deiner Umgebung: Welchen Kartenleser hast
Du, kommt eine CT-API zum Einsatz, wie greifst Du von Java aus auf den
Leser zu? JNI?
Gruß...Bert
Jetzt habe ich mir dieses javax.smartcardio mal angeschaut, tja, das
basiert auf PC/SC, da geht normalerweise nichts mit Speicherkarten wie
der gezeigten, deswegen heißt es ja auch _smartcard_io.
Der Kartenleser ist hier fast nur die physikalische Schnittstelle zur
Karte und setzt keine eigene Intelligenz in die Steuerung der Karte.
Daher hast Du keine Chance festzustellen, was für eine Karte tatsächlich
vorliegt.
So wie ich die Doku von javax.smartcardio verstehe, unterstützt es
ausschließlich Prozessorkarten über T=0 oder T=1 Protokoll. Diese Karten
verstehen dank ihrer Intelligenz APDUs selbst.
Also, ich fürchte, mit den bei Dir gezeigten Speicherkarten wird das so
nichts.
Gruß...Bert
Probier es mal mit der jni2ctapi
(http://www.cardcontact.de/download/jni2ctapi/README.html). Damit habe
ich den Vorgänger der SLE5542, eine SLE4442, erfolgreich ansteuern
können.
Wichtig ist, dass Treiber und Kartenleser den synchronen Modus
unterstützen. Das war bei vielen der von mir getesteten Geräte leider
nicht der Fall. Gut funktionierte es mit Reiner-SCT und
Kobil-Kartenlesern.
Hallo,
also, mein Kartenleser ist ein CHERRY ST-1044u (
http://www.cherry.de/deutsch/produkte/kartenlesegeraete_SmartTerminal_ST-1044U.htm
).
Der sollte die Karten unterstützen, meine ich.
Gut, also PC/SC fällt also aus, ebenso .smartcardio.... Schade
eigentloch, war so einfach -.-
Eine CT-API kam bisher noch nicht zum Einsatz. Es gibt allerdings eine,
die vom Hersteller Cherry stammt.
Das wird wohl dann der nächste Schritt sein.
Das jni2ctapi werde ich mir heute auch mal ansehen - danke für den Tipp,
draco.
Die CT-Api habe ich anfangs aus dem Spiel gelassen, da ich mit dem
Einbinden von dll's keine Erfahrung habe (habs auch noch nie
gebraucht...) - aber ich komme wohl nicht drum herum.
Mal sehen, ob das klappt :-)
mfg
Ja, Du brauchst das JNI, um die ctapi.dll anzubinden.
Die CT-API selbst exportiert nur drei Funktionen, CT_init(), CT_data()
und CT_close(). Informationen dazu findest Du u.a. bei TÜV-IT:
http://www.tuvit.de/downloads/Tuev-IT/CTAPI111.pdf
Dein Kartenleser hält sich vermutlich mehr oder weniger an die
MKT-Spezifikation vom Teletrust:
http://www.teletrust.de/publikationen/spezifikationen/mkt/
Schau Dir auf alle Fälle den Teil 4 an, da findest Du die verfügbaren
Kommandos.
Ein Gotcha wird es noch geben: Das Schreiben auf eine synchrone
Speicherkarte, so wie Du sie verwendest, wird von den üblichen
Kartenlesern oft nicht unterstützt, da man ja so u.a. auch die
Krankenversichertenkarte manipulieren könnte. Die entsprechenden
Kartenbefehle WRITE_BINARY bzw. WRITE-RECORD werden dabei von der FW des
Kartenlesers abgefangen und mit Fehlercode quittiert.
Für eine eigene speicherkartenbasierte Anwendung hatte ich mir
seinerzeit das "Zinker"-Terminal aus der c't aufgebaut, das kann alle
Funktionen, die mit synchronen Speicherkarten möglich sind, unterstützt
dafür aber keine Smartcards:
http://www.heise.de/ct/artikel/Der-Zinker-284202.html
Gruß...Bert
Hi,
also, habe mich eben mal mit dem jni2ctapi beschäftigt.
Das ganze läuft auch, aber der Responsecode bleibt zumeist 6E00.
Draco, du hast es ja damit zum laufen bekommen - also kann es doch nicht
ganz unmöglich sein -.-
Im Anhang der Quelltext des Beispielprogramms von jni2ctapi.
Alle Anweisungen sind an sich erfolgreich (Success) aber trotzdem kommen
die o.g. Fehlercodes zurück.
Draco, du hast nicht zufällig noch Codeschnipsel für mich, wie ich z.B.
"12345" auf die Karte schreibe und wieder auslese?
Irgendwie habe ich ja auch den Verdacht, dass das ganze im Hintergrund
doch wieder mit APDU's abläuft!? Damit kommt die Karte doch nicht
zurecht!?
mfg
Ich hatte damals u. a. den ST-1000 UB im Test. Der war ein bischen
langsam, aber der Zugriff auf die SLE 4442 mittels CT-API hat
funktioniert.
Evtl. könntest Du mal einen ganz alten Treiber für den Kartenleser
probieren, denn viele Kartenleser-Hersteller haben beim Sprung auf den
Smartcard Zug vergessen die "alten" Interfaces für synchrone Karten zu
pflegen und zu testen.
Ach ja, hier ist noch ein 08/15 Code aus allerersten Tests. Es wird ein
"reset icc" gesendet und dann von der Karte gelesen. Den String
"towitoko" musst Du noch durch den richtigen für Deinen Treiber
ersetzen.
sooo,
also, wie du in deiner Antwort am 28.5., 14:28 geschrieben hast, habe
ich eben mal die Kommandos an die Karte geschickt.
Vorweg: Mein CLA-Byte muss immer 0xFF sein, ansonsten kommt der
CLA-Error 6E00 zurück.
Also:
> 0x20,0x11, 0x01, 0x00
da kommt zurück: 90 01 (sieht gut aus, aber warum nicht 90 00?)
dann:
> 0xff,0xb0, 0x00, 0x00, 0x00 (hier das CLA 0xFF, s. o.)
da kommt zurück: 6A 86 (Incorrect parameters P1-P2) - so ein Mist...
Außerdem hat meine Karte ja anscheinend ihre eigenen Commands, z.B. 0x30
für Lesen, 0x38 für schreiben (Datenblatt: http://tinyurl.com/394o547 ).
Wenn ich die 30 teste, kommt "File Not Found" (vielleicht normal, ist ja
nix drauf...) und bei der 38 kommt 6D 00 (Falsches Command) !?!?
Äußerst komisch. Irgendwie hab ich das Gefühl, wir sind dicht an der
Lösung, aber irgendwas fehlt noch -.-
Danke euch für eure Hilfe - wäre cool, wenn wir das noch hinbekommen :-)
hi,
danke für die Links - werde ich mir durchlesen.
Mit den C-Programmen hab ich nichts getestet - komme mit C nicht zurecht
(wobei die Kompiliererei das Problem ist...) - und habe auch keine
Nerven, mich damit zu befassen. Die Chipkarte beschäftigt mich schon
genug -.-
Habe hier http://tinyurl.com/34c2g9a auf Seite 107 gelesen, dass CLA
0xFF das Protokoll T=0 / T=1 auswählt. Will ich aber gar nicht - da die
Karte das nicht kapiert, kommt daher wahrscheinlich der Fehler, dass INS
falsch ist usw...
Aber bei allen anderen CLA-Werten kommt 6E 00 zurück.... ach man :-(
Eventuell unterstützt der installierte Treiber keine I2C Kommunikation
und meckert wenn kein T=0 oder T=1 gewählt wird. Das wäre nicht der
erste Treiber bei dem das so ist.
Bei den Cherry Kartenlesern hatte ich damals, glaube ich,
CT-API_V4_0_1_5.exe verwendet. In dem Archiv ist auch ein Tool
"KVKTool.exe". Damit könntest Du mal probieren auf die Karte
zuzugreifen. Ich hab's mal angehängt.
smartcard schrieb:>> 0x20,0x11, 0x01, 0x00> da kommt zurück: 90 01 (sieht gut aus, aber warum nicht 90 00?)>> dann:>> 0xff,0xb0, 0x00, 0x00, 0x00 (hier das CLA 0xFF, s. o.)> da kommt zurück: 6A 86 (Incorrect parameters P1-P2) - so ein Mist...
90 01 ist der Response für ein RequestICC bei dem eine asynchrone
Smartcard zurückgemeldet wird. Scheint wohl der Fall zu sein.
zu zweitem Fall: Eigentlich ist das Command INS:&HB0 das ISO Commando
für ein Read Binary, welches eigentlich im CLA Register ein 0x00 zu
erwarten hätte.
Bin zwar mit Java nicht vertraut, aber dafür bestens mit der CTAPI.
Gruß
Mario
