Hello,
On 12/06/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
this patch adds two new ATR to the cryptoflex driver
and uses the atr mask to ignore the content of the last
two bytes. maybe we should do that for all cards?
I improved my ATR_analysis program (available from [1]) to also parse
the historical bytes of the ATR.
In the case of the Cryptoflex I have:
ATR: 3B 95 94 40 FF 63 01 01 02 01
+ TS = 3B --> Direct Convention
+ T0 = 95, Y(1): 1001, K: 5 (historical bytes)
TA(1) = 94 --> Fi=512, Di=8, 64.000 cycles/ETU
TD(1) = 40 --> Y(i+1) = 0100, Protocol T = 0
-----
TC(2) = FF --> Work waiting time: 960 x 255 x (Fi/F)
+ Historical bytes: 63 01 01 02 01
Category indicator byte: 63 (proprietary format)
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 95 94 40 FF 63 01 01 02 01
Schlumberger Cryptoflex 16Ko
For a GemSafeXpresso I have:
ATR: 3B 7D 94 00 00 80 31 80 65 B0 83 01 01 90 83 00 90 00
+ TS = 3B --> Direct Convention
+ T0 = 7D, Y(1): 0111, K: 13 (historical bytes)
TA(1) = 94 --> Fi=512, Di=8, 64.000 cycles/ETU
TB(1) = 00 --> Programming Param P: 0 Volts, I: 0 milliamperes
TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 80 31 80 65 B0 83 01 01 90 83 00 90 00
Category indicator byte: 80 (compact TLV data object)
Tag: 3, len: 1 (card service data byte)
Card service data byte: 80
- Application selection: by full DF name
- EF.DIR and EF.ATR access services: by GET RECORD(s) command
- Card with MF
Tag: 6, len: 5 (pre-issuing data)
Data: B0 83 01 01 90
Tag: 8, len: 3 (status indicator)
LCS (life card cycle): 00 (No information given)
SW: 9000 (Normal processing.)
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 7D 94 00 00 80 31 80 65 B0 83 01 01 90 83 00 90 00
GemSafeXpresso 16k R3.2
So that last two bytes are proprietary for a cryptoflex (and may be
the firmware version). But the two last bytes are NOT the firmware
version for a GemSafeXpresso.
if anyone knows the older cryptoflex cards: did they
also have the firmware version in the last two atr bytes?
if so can we ignore those bytes?
Ignoring the two last bytes should be done on a case by case basis only.
feedback on this patch - whether to apply or even use
the atr mask for all atr entries - is very welcome.
I don't think it is a good idea to do that for ALL atr entries.
Bye,
[1] http://ludovic.rousseau.free.fr/softwares/pcsc-tools/
--
Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
