Kommentare zu: Smart Cards durch die in Java eingebaute Java Smartcard I/O javax.smartcardio.* ansprechen

Von: Konstantin Filtschew

Konstantin Filtschew — Thu, 20 Oct 2011 13:23:58 +0000

Hallo Andy,

schau mal nach MD5 (sollte man nicht mehr verwenden), SHA1, SHA256.

java2s Sha1 Example

Gruß, Konstantin

Von: Andy

Andy — Thu, 20 Oct 2011 09:59:47 +0000

Hi Konstantin,

danke für deine Antwort!

>2. Dateiinhalt hashen
Was meinst du damit? Beispiel?

Danke

Andy

Von: Konstantin Filtschew

Konstantin Filtschew — Mon, 12 Sep 2011 11:52:29 +0000

Hallo Andy,

das hängt maßgeblich von der Smartcard ab. Das Vorgehen sollte aber ungefähr so sein:
1. Datei einlesen
2. Dateiinhalt hashen
3. Hashwert an die Smartcard zum signieren schicken
4. Smartcard liefert eine Signatur zurück

Die APDU zum Signieren findet man in der Dokumentation der Smartcard.

Von: AndyM

AndyM — Thu, 08 Sep 2011 20:54:44 +0000

Hi,

kann ich mit Hilfe von javax.smartcardio.* PDF files signieren?? Haben Sie ein Beispiel?

Gruß

Andy

Von: MadMax

MadMax — Fri, 19 Aug 2011 11:23:33 +0000

Ich empfehle, nochmals den Standard 7816-3 genauer zu lesen. Natürlich kann man bei T=0 mit LE arbeiten. Die sogenannten Case-2 und Case-4 Kommandos antworten dann allerdings mit 61 bb, was bedeutet, dass Antwortdaten anstehen, die anschließend mit dem Kommando Get Response abgeholt werden müssen. Kommt allerdings ein 91 bb zurück, so bedeutet dies, dass ein sogenanntes proaktives Kommando ansteht, das man mit einem Fetch-Kommando abholt.

Gruß MadMax

Von: Oleg

Oleg — Wed, 09 Jun 2010 11:26:45 +0000

Hi,

T=0 Protokoll unterstützt LE Byte nicht, das wird erklären wieso LE Byte nicht mitgeschickt wurde. Es muss auf jedenfall bei neuen Karten, wenn LE mitgeschickt werden muss, auf T=1 gehen.

Das mit dem 0x5A to 0×18 vermute ich, dass es an dem “speziellen” Befehl liegt. Wenn ich es in den Wrapper Befehl packe (ist von der Karte vorgeschrieben), funktioniert alles wunderbar, auch wenn den Befehl direkt über “PCSC Test Applikation” sende.

Auf jedenfall hat Konstantin recht: Es ist kein Bug und es wird nix verändert. Die Definitionen sollen einhalten werden , dann klappt vielleicht alles.

Gruß, Oleg

Von: Konstantin Filtschew

Konstantin Filtschew — Tue, 08 Jun 2010 14:56:41 +0000

Hallo Oleg,

normalerweise wird nichts abgeschnitten oder verändert. Wie kommst du drauf, dass es verändert wird? Hast du einen Sniffer an der USB/Com Schnittstelle laufen?

Du hast bei deinem Befehl das Class Byte auf 90 gesetzt. Das bedeutet, du verwendest propriätere Befehle, die nicht in der ISO 7816-4 spezifiziert sind. Da kann ich dir schwer helfen, da ich nicht weiß, was die Befehle bedeuten oder was du vor hast.

Einen Bug in dem Bereich kann ich mir schwer vorstellen. Verwendest du Java Smartcard I/O oder? Es kann noch sein, dass dein Treiber vom Lesegerät ein Problem hat. Das kann ich aber ohne Informationen nicht einschätzen.

Melde dich, wenn du noch Fragen hast.

Gruß, Konstantin

Von: Oleg

Oleg — Tue, 08 Jun 2010 14:01:40 +0000

Hi Konstantin,
ich arbeite gerade an der Kommunikation mit einer Karte über PC/SC und habe ein Problem: lt. Spezifikation der Karte muss APDU nach ISO 7816-4 aufgebaut sein, mit dem Vermerk, dass LE Byte immer vorhanden sein muss, auch wenn es 0×00 ist. Wenn ich APDU aufbaue z.B.: 90 5A 00 00 03 01 00 00 /*LE*/ 00 und diese über CardChannel – Funktion transmit sende, dann wird dieser LE-Byte abgeschnitten und ich bekomme zurück 91 + „invalid telegram“.

Ähnliches Verhalten habe ich auch bei jpcsc festgetstellt. LE Byte wird immer abgeschnitten.

Zusätzlich, wenn ich die Daten mit der Funktion transmit(ByteBuffer arg0, ByteBuffer arg1) sende, also 5A 01 00 00, dann wird die Telegramm geändert und stattdessen 18 01 00 00 geschickt. Als ob es ein Überlauf bei 0×40 statt findet. Ist es ein Bug oder habe ich was nicht beachtet?

Ich werde froh sein, wenn du mir paar Tipps geben kannst. Danke.

Gruß, Oleg

Von: Chris

Chris — Wed, 06 Jan 2010 10:53:23 +0000

Hallo,

ListSmartcardReaders funktioniert bei mir,
Card_Terminal_Name: OMNIKEY CardMan 5×21 0
Card_in_Terminal_present: true

Auch die andere Anwendung geht:
Card_Info: PC/SC card in OMNIKEY CardMan 5×21 0, protocol T=0, state OK
Card Protocol: T=0
ATR: [B@5afd29
ATR historical bytes: [B@1a2961b
response: [B@15dfd77

Musste nur das Protokoll für die Karte ändern auf T=0.
Wollte mich hiermit nur mal bedanken, da ich es für mein Studium brauche !

Kartenleser von OMNIKEY
Karte : von wrankl.de (lag dem buch als Testeksemplar bei)
mfg
Chris

Von: Peter Huebner

Peter Huebner — Mon, 04 Jan 2010 20:59:22 +0000

KVK-Karten? Das sind Memory-Karten, die vom PCSC-Standard nicht unterstützt werden. PCSC kann meines Wissens nur was mit Prozessorkarten anfangen. es gibt in der PCSC-Implementierung unter Windows zwar auch einen (sehr dünnen) Layer, um Memory_Karten mittels (Peudo-APDUs) anzusprechen, meines Wissens nach funzt das aber selten bis gar nicht.
Unter PCSC gibt es kein ReadMemory oder WriteMemory, PCSC funktioniert mit APDUs (T=0 oder T=1), aber Speicherkarten (wie die KVK) können APDUs nicht interpretieren (haben ja keinen Prozessor).
Gruss Peter