On Wed, Jan 12, 2011 at 07:31:43PM +0100, Lionel Elie Mamane wrote:
On Wed, Jan 12, 2011 at 05:57:36PM +0100, Alain Knaff
wrote:
> As far as the java JNI "shim" that loads
the original gemsafe lib
> by absolute path is concerned, maybe this could be tricked by
> renaming the open source driver? Theoretically, the JNI shim should
> only depend on PKCS11 standard APIs, so this might work...
I think I tried that, but it failed. I didn't try
very hard, though.
I looked into it deeper. It does not work for several reasons, some
easier to fix than others:
- I get *tons* of Java errors, even with libgemsafe (the binary-only
driver they provide), and I cannot login fully even with
libgemsafe: the signature is done correctly on the card, but then a
Java error comes and no progress. I do get up to the list of
available cards, though.
I get to the same point with my driver: list of available
cards.
For the next step (actually logging in):
- The LuxTrust code is not fully PKCS#11 compliant, and OpenSC is
more picky about that than libgemsafe: After calling
C_FindObjectsInit, you have to call C_FindObjectsFinal before you
can call C_FindObjectsInit again. (The standard says "At most one
search operation may be active at a given time in a given
session.")
I implemented a work-around in OpenSC, *but* that's not all:
- The luxtrust.lu website uses the *signature* (non-repudiation) key
to authenticate you! That's bad in itself (in essence, the hash you
sign could be the one of a "reconnaissance de dette" and it would
be valid in front of a court), but more to our point, I discovered
that my driver is only able to use the authentication key. Commands
using the signature key have to be cryptographically authenticated
to the card! That's harder to "fake" than plain-text communication
:-/
Here, the easiest would probably be to disassemble the binary-only
driver to get the crypto algorithm and key used for the
authentication; AFAIK this would be legal under article 6 of the
European directive on protection of computer programs.
Then, we still have some implementation work to do, to implement
"secure messaging" (the protocol used to crypto-authenticate the
commands) in OpenSC.
Somebody wants to make a collaboration-project out of it?
--
Lionel