From: Michael Bender (Michael.Bendersun.com)
Date: Fri Mar 19 2010 - 14:52:22 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Mar 12, 2010, at 9:09 AM, Ray Caruso wrote:

> Interesting. How many different cards does your product support?

We support hundreds of different cards but really a large handful of
card families, so that, for example, when we say we support OpenPlatform
cards, you can either count that as one card family or go out and find
all
the OpenPlatform cards you can and count each of those separately. It
all depends on if you are an engineer or a marketing person ;-)

> What do you do when a new type of card comes out?

I'm guessing you really mean what do we do when a new type of card comes
out that is not supported by the Sun Ray (since a new OP-based JavaCard
card could come out and it would be recognized as a OP or CAC or
whatever type card).

> Do you patch?

Someone has to modify an existing smartcard config file or write a new
one,
and then that new file can be installed on a Sun Ray server by the
server
admin or we may include it in a future patch. The delivery method for
a new
smartcard config file has more to do with business decisions than it
does
with technical ones.

mike

----

> On 3/11/2010 12:44 PM, Michael Bender wrote:
>>
>> Yes, that's what we do on Sun Ray (the Oracle thin client). That is
>> the only
>> approach that I could determine would work - each card or card
>> family has
>> unique methods to be identified and to extract a unique ID from the
>> card so
>> the rules for identifying a card and extracting a unique id need to
>> be customized
>> for each card/card family.
>>
>> OpenPlatform cards make things much easier since in most (all?)
>> cases they
>> contain a unique ID that can be extracted from the Card Manager.
>>
>> mike
>>
>> ----
>>
>> On Mar 11, 2010, at 4:23 AM, Sébastien Lorquet wrote:
>>
>>> Yes, I feel it's the right way too.
>>> good luck!
>>>
>>> Sebastien
>>>
>>> On Thu, Mar 11, 2010 at 1:08 PM, Ray Caruso GMAIl <caruso.raygmail.com
>>> > wrote:
>>> Thank you all for your answers. You have pointed me in the right
>>> direction. I found a resource for each card I need to support that
>>> provides the specific PDUs I need to send to get the data I am need.
>>>
>>> Beat regards,
>>>
>>> On Mar 10, 2010, at 11:53 PM, Sébastien Lorquet
>>> <squalylgmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Does this data have a link with what is returned by INIT UPDATE?
>>>> In this case this identifier may not be unique.
>>>>
>>>> Sebastien
>>>>
>>>> On Thu, Mar 11, 2010 at 2:52 AM, Michael StJohns <mstjohnscomcast.net
>>>> > wrote:
>>>> If your card is a global platform card -
>>>>
>>>> 1) Select the default security domain
>>>> 2) do a get data on 00 42 and 00 45 (80 CA 00 42 , 80 CA 00
>>>> 45). The first is the issuer identification number, the second
>>>> is the card image number.
>>>>
>>>> Either or both of these may be set depending on the issuer of the
>>>> card. Pre-issue cards probably don't have these set.
>>>>
>>>> Also (both for GP and non GP cards), if the ATR historical bytes
>>>> begin with 80, those bytes may include an issuer and card number
>>>> or may point to a file on the card which contains them - get a
>>>> copy of ISO 7816-4 for details.
>>>>
>>>> Later, Mike
>>>>
>>>>
>>>>
>>>>
>>>> At 01:30 PM 3/10/2010, Ray Caruso wrote:
>>>>> Thank you for the reply. I am sorry about mis-forming the get
>>>>> data PDU- I truely doubt it required that type of response- it
>>>>> did seem a little rude. I should have written XX CA 00 00 00
>>>>> where XX being the class and I am not sure which instruction
>>>>> class to use. I used FF as a bitmask way of indicated wild
>>>>> carding because all 1's can always be OR'd in.
>>>>>
>>>>> I am reading a manual that states the following:
>>>>>
>>>>> "The appliance will query the smart card for a unique ID, which
>>>>> is a portion of a reply from a “get data†application
>>>>> protocol data unit (APDU) command. The ID contains unique
>>>>> information such as the smart card manufacturer, smart card chip
>>>>> manufacturer, chip type, batch number, etc that identifies a
>>>>> particular card from other cards."
>>>>>
>>>>> I need to emulate the behavior of the appliance. I am able to
>>>>> verify the card token during development.
>>>>>
>>>>> Thanks Again.
>>>>>
>>>>> On 3/10/2010 11:13 AM, Sébastien Lorquet wrote:
>>>>>> Hi,
>>>>>> Â
>>>>>> As I understand, every smart card has a unique IDÂ
>>>>>>
>>>>>>
>>>>>> Unfortunately, that single statement is not true.
>>>>>> Well, it's not even true at the chip level (I guess every
>>>>>> manufacturer has its own system) but there is no standard way
>>>>>> to get this "unique number" in the same manner for all cards in
>>>>>> the world.
>>>>>>
>>>>>> Each card model *may* support an unique id, but it is specific
>>>>>> to the card model, as well as the method to retrieve it.
>>>>>>
>>>>>> that is accessible without security.
>>>>>>
>>>>>>
>>>>>> Â
>>>>>> I need to read this ID from any card within a reader. I have
>>>>>> spent some, but not enough, quality time with the ISO 7816-4
>>>>>> spec and understand the formation of smart card request and
>>>>>> response APDUs (at least I think I do). I have read that I need
>>>>>> to use the get data command as follows:
>>>>>>
>>>>>> FF CA 00 00 00
>>>>>>
>>>>>>
>>>>>> Nice. You need to spend more time on ISO7816 as the FF class
>>>>>> is invalid, it's not a card command but (maybe) a reader
>>>>>> command or something else.
>>>>>>
>>>>>> Moreover if such a magic command existed, someone would have
>>>>>> mentioned it somewhere in google.
>>>>>> Â
>>>>>>
>>>>>> However, this fails to provide the correct ID.
>>>>>>
>>>>>>
>>>>>> Sure. Do you at least know what *is* the correct ID you're
>>>>>> expecting? :-)
>>>>>>
>>>>>> Â
>>>>>> Any help on this would be greatly appreciated.
>>>>>>
>>>>>>
>>>>>> First detect the card model in some way, then pray for the card
>>>>>> to provide a mean to identify itself, then issue the
>>>>>> appropriate valid commands to get it.
>>>>>>
>>>>>> Regards
>>>>>> Sebastien
>>>>>>
>>>>>> _______________________________________________
>>>>>> Muscle mailing list
>>>>>>
>>>>>> Musclelists.musclecard.com
>>>>>>
>>>>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Muscle mailing list
>>>>> Musclelists.musclecard.com
>>>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>>
>>>>
>>>> _______________________________________________
>>>> Muscle mailing list
>>>> Musclelists.musclecard.com
>>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>>
>>>>
>>>> _______________________________________________
>>>> Muscle mailing list
>>>> Musclelists.musclecard.com
>>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>
>>> _______________________________________________
>>> Muscle mailing list
>>> Musclelists.musclecard.com
>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>
>>>
>>> _______________________________________________
>>> Muscle mailing list
>>> Musclelists.musclecard.com
>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>> _______________________________________________
>> Muscle mailing list
>> Musclelists.musclecard.com
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>
> _______________________________________________
> Muscle mailing list
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]