On Tue, Jun 22, 2010 at 3:00 AM,  <[email protected]> wrote:
>
> Message: 1
> Date: Mon, 21 Jun 2010 11:26:29 +0200
> From: Ludovic Rousseau <[email protected]>
> Subject: Re: [Muscle] Suggestion for the big CCID reader matrix.
> To: MUSCLE <[email protected]>
> Message-ID:
>        <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2010/5/25 Ludovic Rousseau <[email protected]>:
>> The 3 lists Supported [1], Should work [2] and Unsupported [3] now
>> contains for each reader the CCID release adding support of the
>> reader.
>> The information is also present in the big matrix [4] in the 'release'
>> column (the last one).

Hi Ludovic,
thank you very much for the very detailed answers.

I checked "supported" devices, and I decided to order USB Shell Token
V2 from Gemalto :
http://support.gemalto.com/index.php?id=61

This one should be supported, and my idea is to use your pcsc-tools to
interrogate SIM card and have idea about results which my embedded SIM
controller driver should get...

>> 2) Are there some Linux applications that you recommend that can be
>> used to easily read and analyze content of the SIM card ?
>
> You can try my "SIM explorer v3.0" [3] software. It uses the Perl
> PC/SC wrapper [4].

OK, thanks, I'll give it a try.

Does it manipulate just phone book, or I can use it to browse/modify
all other files on the SIM ?

I am not very familiar with SIM development yet, but surfing around I saw :
http://www.dekart.com/products/card_management/sim_explorer/

It seems like a tool which can explore contents of the SIM, and can
help during development phase.

Is there some Linux equivalent that you know about ?


> You can also use my online ATR parsing [5].
>
>> How can I analyze this this sequence and confirm at least that it is
>> in good shape (my concern is that I think that it should have 13
>> historical chars (T0 char is 0x9d), but it seems that it list them 15
>> here).
>
> I can't use your ATR without reformatting. You should give it on one
> line only like: 3B 02 14 50

Wow, great tool ! Thank you very much.

Using it I have gotten something like this :

Parsing ATR: 3B 9D 94 80 1F C7 80 31 E0 65 D0 00 2B E6 08 73 FE 21 13 CF

TS = 0x3B        Direct Convention
T0 = 0x9D        Y(1): b1001, K: 13 (historical bytes)
TA(1) = 0x94        Fi=512, Di=8, 64 cycles/ETU (62500 bits/s at 4.00
MHz, 78125 bits/s for fMax=5 MHz)
TD(1) = 0x80        Y(i+1) = b1000, Protocol T=0
----
TD(2) = 0x1F        Y(i+1) = b0001, Protocol T=15
----
TA(3) = 0xC7        Clock stop: no preference - Class accepted by the
card: (3G) A 5V B 3V C 1.8V
----
Historical bytes        80 31 E0 65 D0 00 2B E6 08 73 FE 21 13
Category indicator byte: 0x80
 (compact TLV data object)
    Tag: 3, Len: 1 (card service data byte)
      Card service data byte: 224
        - Application selection: by full DF name
        - Application selection: by partial DF name
        - BER-TLV data objects available in EF.DIR
        - EF.DIR and EF.ATR access services: by GET RECORD(s) command
        - Card with MF
    Tag: 6, Len: 5 (pre-issuing data)
      Data: D0 00 2B E6 08
    Tag: 7, Len: 3 (card capabilities)
      Selection methods: 254
        - Record number supported
        - Short EF identifier supported
        - Implicit DF selection
        - DF selection by file identifier
        - DF selection by path
        - DF selection by partial DF name
        - DF selection by full DF name
      Data coding byte: 33
        - Behaviour of write functions: proprietary
        - Value 'FF' for the first byte of BER-TLV tag fields: valid
        - Data unit in quartets: 1
      Command chaining, length fields and logical channels: 19
        - Logical channel number assignment: by the card
        - Maximum number of logical channels: 3
TCK = 0xCF        (correct checksum)
Possibly identified card: UNKNOWN


Correct checksum in the end gives me a little bit confidence that this
ATR is possibly the real one and well received.

However, T=15 protocol is something that confuses me. Do you have any
idea why it is used, as I have seen so far that only T=0 and T=1 are
used, and the rest is reserved for future uses.
Could this rather be an error in ATR reception ?

Thanks again and best regards,
Drasko

_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to