Moin, Am Wed, 14 Feb 2007 14:34:55 -0800 schrieb Justin Karneges:
> It seems that there are 4 communication areas:
> 1) I/O to the smart card
> 2) I/O to the reader
> 3) filesystem layout/control for reading
> 4) filesystem layout/control for all else
> 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.
That's ISO 7816, which should become your next-to-best friend if you
want to know anything about smart cards. Actually #1 is divided between
at least two parts: 7816-1 to -3 describe physical (size of the card,
location of the contact plates), mechanical and electrical (voltage,
which signal is which) characteristics. Also described are two
transmission protocols (T=0 and T=1) which are used to get bytes to and
from the card.
There you also get the definition of APDUs (Application Protocol Data
Unit) for commands and responses. The second part of your #1, 7816-4
then defines common ("interindustry") commands for most of the basic
operations: selecting files, reading data, updating data, etc. from
existing files. Most notably it doesn't describe commands for creating
files or performing cryptographic operations.
There are also some other 7816-* documents of interest, e.g. -8 for
cryptographic operations and -9 for file creation and management
(though I'm not sure whether anyone fully implements that).
> 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.
Both are the case. As with almost any other standard there are some
points where it's possible to interpret the standard in at least two
ways and one vendor implements one of these and another vendor
implements the other one. There are also bugs. And vendors who
seemingly can't read or don't care. And there are also points where
openct is incomplete.
> 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.
See above: Most cards only implement 7816-4 and -8 and then only a
subset of these. File creation and management has always been very
vendor specific, so in order to actually create PKCS#15 file system you
need to have a card specific driver (which opensc has for a lot of
cards).
> Are there any known cases where PKCS#15 software has been
> incompatible for read access?
Yes, that's the same problem as above: different interpretations, bugs
and incompleteness (e.g. last time I checked opensc couldn't read
HiPath formatted PKCS#15 cards because they use a feature from the
standard which opensc doesn't implement).
> 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.
PKCS#15 is only the layout that you see when reading. As said above,
creating files and directories usually needs some vendor specific magic
(e.g. Siemens CardOS cards need proprietary secure messaging with a
secret key for formatting the card).
Another important problem is that nearly each vendor uses some
proprietory, vendor-specific system for assigning access control
permissions. E.g.:
Cryptoflex has some bytes where the first byte specifies the PIN needed
for reading, the second specifies the PIN needed for writing etc. (or
something like that, haven't looked at it for a long time).
TCOS has a list of 6-byte tuples where in each tuple the first byte
specifies the command that the ACL entry is valid for and the
remaining bytes specify combinations of PINs and keys needed.
Starcos has a state machine where you can define the state that must be
reached in order for a command to be executed and rules for the
transitions between states.
CardOS has some complex system where you can define tests (e.g. PIN x
entered) and then let the execution of a command depend on a boolean
term over these tests, expressed as a byte string in reverse polish
notation (again: IIRC).
SECCOS has a similar system with boolean combinations, but expressed in
a TLV-structure.
Naturally each vendor thinks his system is the best and a market
advantage, so it's unlikely that they will consolidate these.
--
Henryk Plötz
Grüße aus Berlin
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~
pgpXFePbFZXjP.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
