Gunnar,
Unfortunately things are not as easy as you make out. How many card
platforms use ISO encoding of the ATR historical bytes? I recently analysed
ATRs from an IBM card and a ChipKnip (Proton) card for Magnus Therning, and
both use proprietary coding for the ATR historical bytes. Are those card
issuers committed to maintaining the same ATR coding? Can we be sure that
they do not clash with any other card?
Even when a card platform uses ISO encoding in the ATR historical bytes, we
still have to go to each manufacturer/issuer in turn to ask them to promise
not to change things. But this is getting off topic, as it is getting us
into the more general problem of interoperabilityof card platforms, a
problem which the eEurope work is trying to get to grips with.
I note, however, from taking another look at ISO 7816-4, that it does
provide for information needed to identify the card platform to be available
from the "card identification service" (clause 9.2), and that the commands
associated with these services "use CLA = '00', i.e. no secure messaging and
the basic logical channel" (9.1).We could still be offered a card platform
that will not let you access ANYTHING beyond the ATR until a successful
security challenge has taken place. Does OCF support the card identification
service? Do any cards support it?
ITSO has in fact decided to classify both the card platform (COS) security
scheme and their application related-security, and to encode that info in
either their DF or (aspirationally) in a new data object type in the ATR.
The problem of maintaining a large installed base of terminal equipment (of
many different types from many different manufacturers) and their SAMs is
yet to be addressed.
Peter
----- Original Message -----
From: "Gunnar Osterode" <[EMAIL PROTECTED]>
To: "Peter Tomlinson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 31, 2001 10:07 AM
Subject: Re: [OCF] Argh! getSmartCard hassles
> Of course, ATR cannot be used to get information about the functionality
of
> applications residing on the card, but the ATR has to give information
> about the used COS and that's all you need at the level of
OCF-CardServices.
>
> As you mentioned, furthermore there has to be a standardisation of
> applications. I think a good approach is the PKCS#15 published by RSA
> Security. What do you think about it?
>
> Regards
> Gunnar
>
> >And here, once again, we hit the problem of identifying a card from its
ATR.
> >I well remember a vending equipment manufacturer telling me that a South
> >American e-purse card was being identified as a Proton card by his
equipment
> >(the Sth Am card was a local design). You cannot rely on the ATR to ID
the
> >card, and the problem gets even worse when the card is a multi-app
platform.
> >
> >Here in the UK, a group known as ITSO (www.itso.org.uk) has been trying
to
> >develop a general application spec for public transport ticketing and
> >related functions. They expect their app to be capable of being hosted on
> >many card platforms. So they decided to define a classification system
for
> >card type, security scheme type, and security key set. Then they have to
> >work out how to implement this. So they have decided to ask ISO to create
a
> >new object type in an ISO-structured ATR, and this object will contain
the
> >class info for the ITSO application and associated security mechanisms.
How
> >many card platforms have an ATR that has an ISO structure? How many card
> >platform providers are willing to let an app shove something into the
ATR?
> >
> >While investigating ITSO's ideas for a citizen card scheme, and after
some
> >discussion with two major card platform providers, I proposed that the
card
> >platform must be capable of supporting Select File with direct AID
> >addressing of a DF, and that the card platform's security scheme must
allow
> >read access to the ITSO DF without any prior security exchange (i.e.
prior
> >knowledge of the card's security mechanism is not available in the
terminal,
> >because it doesn't know what the card is), and that the ITSO class info
must
> >then be freely readable from the DF. After that the terminal can
configure
> >itself (from info stored in the terminal or in a SAM) and carry out any
> >mutual authentication procedure deemed necessary by the scheme owners
and/or
> >card issuers.
> >
> >This, of course, presupposes that the card supports ISO file structures
and
> >the requisite form of Select File. Not all card platforms support that
form
> >of Select File, and Javacard has made ISO file system support optional...
> >
> >Peter T
> >
> >----- Original Message -----
> >From: "Gunnar Osterode" <[EMAIL PROTECTED]>
> >To: "Marc Palmer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> >Sent: Wednesday, January 31, 2001 8:58 AM
> >Subject: Re: [OCF] Argh! getSmartCard hassles
> >
> >
> > > Hi Marc,
> > >
> > > the CardRequest-object is not "senseless". The CardRequest-object
> >specifies
> > > the CardService which is required for the purposes of the application.
For
> > > one card there can be many available CardServices. For instance
> > > FileAccessCardService or SignatureCardService.
> > >
> > > If a card is inserted, the ATR is passed to all CardServiceFactories
that
> > > are registered in the opencard.properties file. Now the factory has to
> > > decide if the ATR specifies an available cardtype and if for this
cardtype
> > > the required CardService is available. If the card doesn't match your
> > > requirements you can't use it for the purposes of your application and
> >need
> > > not to create a SmartCard object.
> > >
> > > Nevertheless I'm also not completely happy with the current mechanism.
In
> > > my oppinion it would be helpful in some cases if I could ask for an
> > > Enumeration of available CardServices for an inserted CardType.
> > >
> > > Kind regards
> > > Gunnar
> > >
> > >
> > > >Hi,
> > > >
> > > >I'm trying to use SmartCard.getSmartCard to get a SmartCard reference
> > > >when a new card is inserted (i.e. I'm doing this in cardInserted)
> > > >
> > > >However, many of the method signatures have been deprecated as of OCF
1.2
> > > >and the one I am supposed to use is:
> > > >
> > > >getSmartCard( CardTerminalEvent, CardRequest)
> > > >
> > > >Now this seems really stupid to me, as I have to create a CardRequest
> > > >object using values taken from the even I'm passing to getSmartCard!
As
> > > >far as I can see the only difference is the int value for
> > > >ANYCARD/NEWCARD, which is all I really need to specify (the rest can
be
> > > >gleaned from the event).
> > > >
> > > >Does anyone know why this is?! Surely it would make sense to have:
> > > >
> > > >getSmartCard( CardTerminalEvent, int reqCardType)
> > > >
> > > >Where the value of the second parameter is CardRequest.ANYCARD or
> > > >CardRequest.NEWCARD. This saves the hassle of creating another
> > > >"senseless" object.
> > > >
> > > >Oh well...
> > > >
> > > >Cheers
> > > >
> > > >
> > > >
> > > >
> > > >---
> > > > > Visit the OpenCard web site at http://www.opencard.org/ for more
> > > > > information on OpenCard---binaries, source code, documents.
> > > > > This list is being archived at
> >http://www.opencard.org/archive/opencard/
> > > >
> > > >! To unsubscribe from the [EMAIL PROTECTED] mailing list send an
> >email
> > > >! to
> > > >! [EMAIL PROTECTED]
> > > >! containing the word
> > > >! unsubscribe
> > > >! in the body.
> > >
> > >
> > >
> > > ---
> > > > Visit the OpenCard web site at http://www.opencard.org/ for more
> > > > information on OpenCard---binaries, source code, documents.
> > > > This list is being archived at
http://www.opencard.org/archive/opencard/
> > >
> > > ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an
email
> > > ! to
> > > ! [EMAIL PROTECTED]
> > > ! containing the word
> > > ! unsubscribe
> > > ! in the body.
> > >
> > >
>
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
