Justin Karneges wrote:
Is the problem that these cards don't support 7816?

7816 is a big family of standards, and the last parts of
it came quite late. at that point every vendor already had
a card implementing his own commands etc.

and because certifications are very, very expensive, why change
something you have, works and is certified, even if it is not
standard? only the software on the host cares about that, and
most vendors make good money selling card and software.

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 ?

no, the sign() function needs to know about those hacks and implement
them. currently opensc doesn't work with siemens hipath initialized
cards, because we don't support their hack yet. you can read all files,
and use the keys for decryption, but not yet for signing.

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.

gemalto cryptoflex smart cards already have usb on the smart card chip.
they require only a small adapter for the usb format (one with no logic
on it). IIRC eu funded development of stuff like this too, but I guess
companies developed it, but then didn't use it - would require to
certify the new product and that is very expensive.

Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to