At 14:40 21/07/2003 -0700, Michael Bender wrote:
H�seyin ORTAOVALI wrote:
Shame on the smartcard industry for not providing a universal way to identify a card tpye and to extract a unique ID. This isn't exactly a new concept in the field of electronics and computer-connected devices.
Smartcard industry mainly complies with standards it has to follow
The smartcard industry *creates* the standards that it follows, so that's not really a good justification for a lack of a universal scheme to identify cards.
if you except an unique ID for all GSM, banking, ID (memory?) cards
> you may indeed fail to find one since these standards are differents > (actually nearly all cards but GSM provide a CPLC string as per > EMV96 or VIS1.x.x)
A mechanism for identifying hardware as to vendor, type, model and providing a unique ID has been developed for many other computer technologies that are governed by standards that are developed by numerous technology companies, many of them competitors. Consider the following technologies:
EISA
PCI
PCMCIA
USB
Ethernet
802.11* (wireless)
Serial Plug-and-Play
IEEE 1394Oh, and double shame on the industry for allowing different AIDs for OpenPlatform/GlobalPlatform Card Manager applets so that what could have been a reasonable way to determine card type and serial number information doesn't work in many cases.
one provider uses a proprietary AID, it isn't a rule.
Still some cards use A0000000030000 and others A000000003000000 but selection with partial AID is supported by most of them so "A000000003" can work as well.
Yes, but why do we even allow this "partial AID" selection hack and allow manufacturers/issuers to use different CM AIDs? Why no set it in stone in a standard that specifically and unambiguously spells out what every card must do to identify itself?
IMHO, the industry has reaped what it has sowed over the past twenty or so years by steadfastly refusing to work together and continuing to propogate proprietary solutions for no good reason.
I'm afraid your point is definitively wrong. All GSM cards comply with 11.11 & 11.14, all banking cards comply with EMV certification - meaning aroud 99% of issued cards !...
I'm sorry, but I believe that my point is correct - there is no one single standard in the smartcard industry that all cards follow in the area of identification and serial number/unique ID extraction.
considering that card providers can do their own stuff is a mess, they do what specification issuers request, and they request the same to all card providers.
The responsibility here is with the technology providers, but what you say is typical of all the card vendors that I have worked with over the years - everyone just passes the buck and says "it's not my problem, my customer wants it this way".
Think about this - what if when you went to your local computer store and bought a PCI card, say a VGA card or a sound card or some other peripheral card when you plugged it into your system the system had no way to identify the card nor what resources it needs, and you needed custom manufactuer-provided software to just get to the point where the system knos that it's a VGA or sound or modem card, and in the process of running that custom software you had a good chance of crashing the system or scrambling other cards in the box? No one would stand for this in today's computer world, yet we can't seem to get the smartcard industry to even agree on a simple, universal identification scheme that doesn't require poking random APDUs into unknown cards to see what happens.
the comparison sounds strange !! a GSM card is as different than a banking one than a video card is different than sound card, PC industry had defined its own standards to (of course recognize these cards and) use them for a specific function; smartcards behaves the same: they behave as expected when plugged in the dedicated device.
does your VGA card runs well in a hi-fi systems ?
You miss my point completely - my example of PCI cards is that *all* PCI cards will identify themselves using the same mechanism. They all provide vendor/model/ID and resource requirements information. I can write one piece of software that will query any PCI card produced and get basic information on the card.
That is simply not possible with a smartcard.
As to whether a VGA card runs well in a HiFi system, my answer to that would be - maybe, if the HiFi system is computer based and has a connector for a VGA card that provides the display for the HiFi system.
As for the VGA case specifically, the computer industry has even gone so far as to define the basic set of VGA operations and parameters that all cards must follow in order to produce a usable video signal. That is way beyond simply identifying the card as to type and ID.
Where are we in this regard in the smartcard space?
Think about the ATR - what an absolutely wonderful place that would have been to embed a multi-byte product/family/vendor code as well as a unique ID; you reset the card, and then you get all the info you need in a single transaction to know if the card in the reader is one that you can work with.
yeah, could be great, but again ATR is defined by ISO 7816-3 & 4, not by card providers, and ISO didn't define a card manufacturer tag (a "pre-issuance data" field still exists).
Who defined ISO 7816? Was it handed down from the sky by some cosmic entity or by space aliens from the Planet X?
Come on, the smartcard industry defined ISO 7816, so it's really disengenuous for you to say that the smartcard industry is only following the standard, when they defined the standard in the first place, and because of their lack of technical foresight and nationalistic pride and unwillingness to produce anything by closed, proprietary systems, we have an ISO standard that is regarded by many as a document that describes *exceptions* rather than one that is truly a standard.
Let's talk about GetResponse processing for example - why are there so many possible status words that the card can return, and why is there no concrete statement that specifies where such processing is supposed to be done - in the terminal, in some middleware software stack component, by the application? What possible justification can *anyone* provide for this mess?
I know, I'm probably preaching to the chior, but I have very little patience when I hear the industry complaining about how smartcards have not been as embraced by the general public for general computing applications.
I think smartcard industry does not complain about that, it's a 1-3% market!!
Yes, that may very well be, but it could be a much larger market if the industry was willing to come up with reasonable, rigid and non-proprietary standards.
The main reasons that prevent cards to be used in public is more: leak of readers, why M$ does not list smartcard reader as a required device?
Is Microsoft the only opeating system vendor in the world?
How about the fact that I can't go down to my local computer store and buy a ten-pack of Schlumberger smartcards today, and buy a ten pack of Oberthur smartcards tommorrow, and have exactly the same code work on both sets of cards? I think it's because the industry is more interested in selling ten million cards to a government tansportation agency than selling ten cards to a million small time developers. Hey, that's a business decision that I don't agree with, but I am not a card manufacturer or issuer, so I can only have an opinion on the matter.
leak of application standards, OCF is great but is it better than CSP ?, would I use PKCS#11 ? most of software developers are not interested in smartcards (for security, license management, authentication, identification, data storage, ....) just because they can't rely on a mature API to provide these features.
The whole host-side API mess has not been helped by the two distinct camps - PC/SC on one side and OCF/Java on the other. As a developer of host-side smartcard applications, it makes it really hard for me to release one piece of code that will work on all systems; I've given up the OCF torch and am doing PC/SC these days.
sorry for this out of (list) subject mail.
Well, it's better than reading yet another post from Sam Goldsmith advertising 10,000 Gemplus readers for sale, so thank you for the diversion :-).
mike
-- ---------------------------------------------------------------------------- Michael Bender E-Mail: [EMAIL PROTECTED] Sun Microsystems, Inc. Tel: 831-401-9510 14 Network Circle Tel: x.31807 Menlo Park, Ca. 94025 Mailstop: UMPK14-260 MD: VPN/IMAP
Never give up! Never surrender!
----------------------------------------------------------------------------
---
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.
