On 12/01/11 17:33, Lionel Elie Mamane wrote: ok... I guessed that much, but still wanted to be sure. As far as I know, they market it as being "more professional", not more secure, and this has more to do with the features that Luxtrust's PKI supports on the various media, rather than the intrinsic security. Most important feature here is that the credit-card sized cards support signature by multiple cards, which is useful in an enterprise context if signatures of more than one decision-taker are necessary to validate a given business transaction. Moreover, Luxtrust provides a fraud insurance with their media, and the amount insured is higher for the credit cards than for the SIMs. Another fun fact is that the sticks are guaranteed for 5 years, but the credit cards only for 3. Apparently, this is for purely mechanical reasons: contacts of the credit cards wear faster than for the sticks (because the SIM is only inserted into the stick once, and then stays there), and so the credit card would never last 5 years. Interesting. No Pb Yes, noticed that too (... but only had noticed it _after_ I've already found it out by other means...) Weird. I use it on an Ubuntu 10.04, which is also fairly recent (came out last year). But I did notice that opensc based _applications_ cannot use the Gemsafe PKCS11 module (even on older Ubuntu 8.04), supposedly because the two copies of opensc "fight" each other (the "dynamical" copy pulled in by the app, and the static one brought by the PKCS11 module). No such problem exists for apps that don't use OpenSC directly (such as Firefox). Btw, this is how I first noticed that Gemsafe uses OpenSC :-) It might be interesting to see whether the Gemsafe module fails on lenny for all apps (including Firefox), or only for those that use OpenSC (various handy command line "test tools") Also, legally, their licenses are an interesting mess. They did include the LGPL for openSc in their package, but then put their own license (for the proprietary parts) next to it, and both licenses basically contradict each other (and there is no text which says which should count more). I would guess, in case of doubt the OpenSC LGPL license should count, because they would not legally be allowed to "remove" anything from the OpenSC license or else they would forfeit their right to build upon OpenSC... 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... the C PKCS11 API) was lacking some features which they "needed" (such as chosing among more than one card that might be present), so they had to resort to this "hack" if they wanted to offer these features from Java. The C PKCS11 API does have the required features, so there is no reason why any standard complying PKCS11 module shouldn't work, if it had the "correct" name.... Regards, Alain

On Wed, Jan 12, 2011 at 07:31:43PM +0100, Lionel Elie Mamane wrote: 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

On 14/01/11 09:59, Lionel Elie Mamane wrote: Two years ago, I started working on a disassembler, which might come in handy here. Yesterday, I tried to follow your instructions in http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools , but unfortunately the tools segfault: GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /some/place/bin/pkcs15-tool...done. (gdb) r --list-keys Starting program: /some/place/bin/pkcs15-tool --list-keys [Thread debugging using libthread_db enabled] Using reader with a card: Gemplus GemPC Key 00 00 Program received signal SIGSEGV, Segmentation fault. __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31 31 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. in ../sysdeps/x86_64/multiarch/../strlen.S (gdb) bt #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31 #1 0x00007ffff7216d76 in *__GI___strdup (s=0x0) at strdup.c:42 #2 0x00007ffff77601b6 in sc_dup_app_info (p15card=0x618220, aid=<value optimised out>) at pkcs15.c:706 #3 sc_pkcs15_bind_internal (p15card=0x618220, aid=<value optimised out>) at pkcs15.c:749 #4 0x00007ffff77613bb in sc_pkcs15_bind (card=0x60c2d0, aid=0x0, p15card_out=<value optimised out>) at pkcs15.c:946 #5 0x00000000004055cd in main (argc=2, argv=<value optimised out>) at pkcs15-tool.c:1781 I checked with strace where it was getting the libs from, in order to make sure it was not mixing system libs with its own: Using reader with a card: Gemplus GemPC Key 00 00 zsh: segmentation fault strace -fo logg /some/place/bin/pkcs15-tool --list-keys 14072 open("/lib/libcrypto.so.0.9.8", O_RDONLY) = 3 14072 open("/some/place/lib/libopensc.so.3", O_RDONLY) = 3 14072 open("/lib/libpthread.so.0", O_RDONLY) = 3 14072 open("/lib/libc.so.6", O_RDONLY) = 3 14072 open("/lib/libdl.so.2", O_RDONLY) = 3 14072 open("/lib/libz.so.1", O_RDONLY) = 3 14072 open("/usr/lib/libltdl.so.7", O_RDONLY) = 3 14072 access("/lib/libpcsclite.so.1", R_OK) = 0 14072 open("/lib/libpcsclite.so.1", O_RDONLY) = 3 So it does get libopensc.so.3 from /some/place (which is good). For libpcsclite.so, it uses the system lib, but as /some/place contains no libpcsclite.so, I suppose this is ok? Segfault does not happen if no stick is inserted. Any ideas? Thanks, Alain

On Tue, Jan 25, 2011 at 11:50:10AM +0100, Alain Knaff wrote: Here's a patch. Or use SVN revision r5052, which as far as I remember does not have this bug yet. I'm filing the bug in their bug tracker. -- Lionel

On 01/25/2011 06:20 PM, Alain Knaff wrote: ... and in Mozilla it works now too (tested by connecting to https://www.services-publics.lu/assistants/espace-perso) ... so I suppose that with pkcs11-tool I might just not have used the right syntax. Any help here? Thanks again, Alain

On 01/25/2011 08:15 PM, Lionel Elie Mamane wrote: [...] Indeed that works, thanks. Actually, I had already tried this earlier, but it took so long that I mistakenly believed it was hung... ... btw, is this long wait expected? I seem to understand that there is some caching functionality, maybe for me this is off for some reason? Another strange thing: Logging in to "GemP15-1 (User PIN)". Please enter User PIN: C_SeedRandom() and C_GenerateRandom(): seeding (C_SeedRandom) not supported ERR: C_GenerateRandom failed: CKR_GENERAL_ERROR (0x5) Digests: all 4 digest functions seem to work MD5: OK SHA-1: OK RIPEMD160: OK Signatures (currently only RSA signatures) testing key 0 (User Cert Sig ) error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101) Aborting. /some/place/bin/pkcs11-tool --slot 1 --module=/some/place/lib/opensc-pkcs11.s 0.01s user 0.04s system 0% cpu 24.305 total Why does it say CKR_USER_NOT_LOGGED_IN? My pin was correct; indeed, for an incorrect pin I get this: Logging in to "GemP15-1 (User PIN)". Please enter User PIN: error: PKCS11 function C_Login failed: rv = CKR_PIN_INCORRECT (0xa0) Aborting. /some/place/bin/pkcs11-tool --slot 1 --module=/some/place/lib/opensc-pkcs11.s 0.01s user 0.04s system 0% cpu 18.292 total Alain

On 01/25/2011 11:28 PM, Lionel Elie Mamane wrote: Yes indeed, now it is *much* faster, and the browser is actually usable with certificate enabled :-) Maybe, it would be a good idea to add that info (and your patch to fix the NULL label bug) to the wiki page? [...] I see... I have a disassembler (decompiler) "half-way" going. It doesn't produce any compilable code yet, but it may be able to dig out some data, such as keys. But due to the volume of code, I'd need some hints about where to look... Are other commands also cryptographically signed (in a way that you have cracked already)? If this is the case, it should probably be easy to find the missing key (by searching for the key that you already have... and hoping that the missing one is stored near it...) Or is it that the "normal" commands are not signed at all? ok, I see. Well, the first 3 seem to be related, but for these last 2, they really should have used a different error code. Unfortunately, we see this kind of thing in far too many apps. Recently, I've been pulling out my hair over a "bad password" error in horde, and the actual error turned out to be nothing like "bad password"... but they simply assumed this was the most common error, so always used the same message for all imap connection related issues... Thanks, Alain

On 26/01/11 09:14, Lionel Elie Mamane wrote: [...] I'd like to, but unfortunately I can only "view source" on the c3l wiki, even after creating an account... [...] Good idea. The next 3 weeks, I'm somewhat busy, but starting from mid of February my availability is better. I think it is doable... but it's more a matter of "finding a needle in the haystack". By having a rough idea where to start, it may make it easier to locate the relevant code. It's already been over a year ago since I last did any disassembly of the Luxtrust middleware, but as far as I remember, it is made up of several modules (different shared libraries). Like a PKCS11 middleware sitting on top of a PKCS15 module, which itself sits on top of some proprietary Gemsafe thingy, which then talks to pcscd via socket. Is this the standard way to implement such modules (i.e. is a PKCS11 always implemented as a frontend to a PKCS15 module)? If so, where would this encryption happen? In the PKCS11 front-end, or in the back end? Also, PKCS11 has lots of API entry points... which API function needs the additional encryption? As far as I understand there is one function that needs it, and another one, which is quite similar, which doesn't need it. By comparing the code of both side-by-side, it should be "easy" to see what is different. Disassemblers, yes (such as objdump). I used objdump in my decompiler, and then postprocess its output. ... yes, but unfortunately we'd pretty much need a decompiler, in order to be able to make sense out of it... There are also free decompilers, but most of these are ages old, don't work with code generated by current compilers, and even less with shared libraries. And most free decompilers out there also look "somewhat" unfinished too... possibly, the symbols might give hints... It calls opensc in lots of places... When I'll have more time, I'll have a look at the "decompiled" code, to see whether I can find anything... Interesting... This is weird, as I've got the impression that PIN was by application session. I.e. app A connects, supplies the PIN, can use the card. When now app B comes, it will have to re-supply the PIN (rather than being able to re-use the PIN entered by A). This can be seen easily by doing a pkcs15-tool -t twice in a row, first time with login, and second time without... The second time it says "Verify: not logged in, skipping verify tests". If login was until card reset, shouldn't the second invocation work without -l? Regards, Alain