On Mon, Aug 23, 2010 at 16:02, Goran Rakic <gra...@devbase.net> wrote:
> Hi all,
Zdravo Gorane! :)
Thanks for the interesting info. I went through the process of reverse
engineering Italian eID two years ago, albeit with much more official
information than you have (we already had a full official
specification of the smart card commands). I'm not a long-time expert,
so I'll put my 2 cents, but I'll be very happy to be corrected by the
list.
> The smart card contains full name, place and date of birth, current
> address, unique citizens number, eID number, photo (fingerprint data and
> electronic signature should also be there). Certificates for legally
> binding digital signatures are included on the card.
Great. I am not 100% sure, but if I've read correctly, this is done
following EU directives about digital signature; IIRC, they forbid the
usage of the same key pair for both legally binding ("qualified")
digital signatures and for web authentication (key wrapping). So, you
probably have two sets of "X.509 certificate + public key + private
key".
> From what I saw, the smart card is in ISO 7816 format (I do not know how
> compatible, it is just what I used to get public data of the card). I do
> not know what would be required to implement the support for this card
> in OpenSC or is it already supported using some of the standard modules.
Most commands are probably already implemented in OpenSC. You can try
running opensc-explorer and using "cd" and "cat" to look at the files
you already know. It is entirely possible that "ls" does not work.
> I can run the middleware inside the VM and trace calls to my reader
> using usbmon, analyzing them with logdecode from carddecoders. My plan
> is to do the tracing during the digital signing and I hope this will
> give me some interesting findings about the card.
It should. Another option you have is to use "apduview":
http://www.fernandes.org/apduview/index.html, in either a virtual or a
physical machine. It works by making the software load a PC/SC library
(winscard.dll) that acts as a shim, logging all exchanged APDUs and
relaying the function calls to the original library, which will
perform the actual communication with the card. It should be a tad
easier, because you can trace APDUs to any card and reader supported
by Windows' own PC/SC API without having to decode the reader's
protocol. I've used it on Windows XP a lot of times without any
hiccups.
> Is this how the things are supposed to work? Should I try something
> different first? Is there some documentation available on how one can
> add support for a new card? I read somewhere that card driver and the
> PKCS#15 emulation are required for every smart card, is that true?
Yes. The card driver will issue the correct APDUs to your smart card,
recognize it, handle any quirks, and so on. The PKCS #15 emulation
behaves like a higher-level driver, if I may say it that way. It knows
where the data files and the certificates are, it knows how to decode
them, and it knows the correct sequence of commands to perform certain
operations (decryption, signature computation…). It presents all of
this to OpenSC's upper layers, so that they can get data files and
invoke crypto operations.
You're welcome to ask for clarifications, help with decoding or anything else!
Regards,
--
Emanuele
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
