On Thursday 15 February 2007 11:00 am, Andreas Jellinghaus wrote: > Justin Karneges wrote: > > There would appear to be a standard for #1. I don't remember what it is > > called, but it involves the ATR and then T=0 or 1 and friends. However, > > my experience with hacking on the Eutron driver showed that that either > > there are still vendor-specific issues (bugs? workarounds?) to iron out, > > or OpenCT is simply incomplete. > > only basic - some cards only have t=0, some have t=1. and due to > restrictions in som readers that is real important. the commands have > to be different dependend on the t=0/1 protocol in a few cases. and > the commands are de-facto different for each card operating systems. > or if the commands look the same, the metadata or the security model > is different. > > and when you have a standard - like a national eid card - then every > country has a different standard, so you are back to square one. the > current reality is: plan to support many different card operationg systems.
Is the problem that these cards don't support 7816? > > For #2 we have CCID. This seems to be about the only thing we can count > > on to work. Can anyone correct me? > > the pinpad/display part of ccid was added in pcsc v2 part 10 and > basically combines five different and incompatible methods into one > standard. so at least pinpad/display is still a mess I think. Multiple ways to do the same thing is not great, but if they are at least specified then it means interoperability can be achieved. > and not all readers are ccid complient - new ones yes, but we still > have lots of old hardware around. As a user, I'm less concerned about old hardware, since smart cards have not touched the casual user market at all (you still cannot even go to a computer store and buy a usb token, at least not in the USA). This means there is time for revision, and as a buyer I can stick to CCID-compliant readers only. > and then there are ugly hacks. for example siemens cardos does not allow > to have a key that can be used for signing and decryption at the same > time. opensc has a "split-key" hack: create two keys with the same > content, but present them as one. siemens itself uses a different hack: > they "sign" with the decrypt function. so these normal use cases > contain problems. While a very ugly problem for writing, I hope this is transparent to read/use ? > > Correct me if I'm wrong, but would ICCD count as a standard for both #1 > > and #2? I'm confused about this, because if we already have a standard > > for #1 (ATR, T=0, whatever), then it doesn't seem like we need the ICCD > > spec at all. CCID would be enough. > > if it is what I think, it is only like ccid - even if the card inside > the token is fixed and not flexible like in a ccid reader, and thus it > can be a lot simpler, still each card is different, not all might have > t=1 protocol, and the apdu commands (or data) is different for each > card, too. Not much of an improvement. And that is what I don't understand about ICCD (maybe I should just read the document closer, heee). It seems like you could already build a single chip usb token that advertised itself as a CCID reader with a single slot. No need for ICCD. > in theory there could be an iso 7816 card with no proprietory commands I > guess, but I doubt there is one. I'm not even sure iso 7816 specifies > everything usualy found in card manuals, e.g. the security model. This seems to be the crux of the standardization problem: having enough standardized commands. If there were enough for read/use (not write), that would be a good start... -Justin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
