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.
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.
and not all readers are ccid complient - new ones yes, but we still
have lots of old hardware around.
For #3 we have PKCS#15. Why this only applies to reading, I don't know, but
99% of smart card applications are read-only so this is still a very worthy
standard, if it works as advertised that is. Are there any known cases where
PKCS#15 software has been incompatible for read access?
pkcs#15 is for read/use-only. once you need to change things, it doesn't
help. even basic operations like unblock pin - no idea if the standard
is good enough so it will always work.
opensc had a problem with relative vs. absolute paths. I hope it is
fixed now, but other software might run into compatibility issues too.
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.
For #4, I guess there is nothing yet. I don't quite understand this, since
anything readable as PKCS#15 must have also been written as PKCS#15, but I'm
sure someone can step in and explain this.
all else is proprietory and undocumented and not standardized usualy -
like eid addons (one standard per country I guess). or like how to
initialize and change cards etc. also the security model of cards is
very different, and for example some cards are one way: you can create
structures but not delete anything (e.g. starcos except if you have a
test version).
And then there's ICCD. I briefly looked at the usb.org PDF file, and indeed
it does look like a standard for integrated USB crypto tokens. It is dated
April 2005. Does anyone know what is going on with this specification, or if
any devices are in development for it?
no idea. I hoped it was CCID stripped down but still compatible, but no
idea. IIRC the usb interface looked the same, but only from a very, very
distant and quick glance at it.
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.
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.
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
