12 Jan
2011
12 Jan
'11
1:46 p.m.
Hi,
I'm pleased to report that I've developed a free software driver /
middleware for LuxTrust-issued smartcards. Details at
http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools
Let me know of your experiences with it.
As usual, it should work on any Unix-or-clone-supported architecture,
not only Intel 32 bits.
That driver is not 100% my work, by far. As Newton said, I've been
standing on the shoulders of giants. First and foremost the whole
OpenSC framework development team and contributors, but also Georges
Bart; my patch to OpenSC is based on his, and on the existing GemSafe
v1 driver in OpenSC (LuxTrust cards are GemSafe v2 cards).
Now you know what I've been up to during hack.lu instead of listening
to the presentations :)
--
Lionel
12 Jan
12 Jan
2:15 p.m.
On 12/01/11 14:46, Lionel Elie Mamane wrote:
Hi,
I'm pleased to report that I've developed a free software driver /
middleware for LuxTrust-issued smartcards. Details at
http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools
Let me know of your experiences with it.
As usual, it should work on any Unix-or-clone-supported architecture,
not only Intel 32 bits.
That driver is not 100% my work, by far. As Newton said, I've been
standing on the shoulders of giants. First and foremost the whole
OpenSC framework development team and contributors, but also Georges
Bart; my patch to OpenSC is based on his, and on the existing GemSafe
v1 driver in OpenSC (LuxTrust cards are GemSafe v2 cards).
Now you know what I've been up to during hack.lu instead of listening
to the presentations :)
This is great news, congratulations! This is useful not only for 64 bit
processors, but also for non-Intel Linux devices such as the Nokia N900.
I suppose this works both for the credit-card sized smartcards and for the
"signing sticks" (which take a SIM-sized chipcard)?
Just out of curiosity: how did you manage to do this, how did you (or Georges
Bart) get the necessary information for this development?
As Lilux, we have had contacts with Luxtrust in order to get the necessary
information, unfortunately we were told that they themselves didn't have it
(apparently Gemalto was not even giving Luxtrust the sourcecode). However,
these silly "Java" glue libraries that you are mentioning on your site have
been written by Luxtrust. Back then, they agreed that _if_ a 64 bit driver was
available from another source, they would also follow with their libraries (...
as there was no point in doing this if no backend was available...). As the
backend is now available (thank you very much for this), it might now be
interesting to take up contact again.
Btw, I had a peek in Gemalto's own drivers (using a crude decompiler), and
apparently they heavily use OpenSC themselves...
Regards,
Alain
4:33 p.m.
On Wed, Jan 12, 2011 at 03:15:38PM +0100, Alain Knaff wrote:
On 12/01/11 14:46, Lionel Elie Mamane wrote:
> I'm pleased to report that I've
developed a free software driver /
> middleware for LuxTrust-issued smartcards. Details at
> http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools
This is great news, congratulations! This is useful
not only for 64 bit
processors, but also for non-Intel Linux devices such as the Nokia N900.
I suppose this works both for the credit-card sized smartcards and for the
"signing sticks" (which take a SIM-sized chipcard)?
Yes. From the software POV, the SIM-sized smartcard and the
credit-card sized smartcard are identical; they present the same ATR.
The only difference I could see is the size of the keys on it; if
memory serves me right the SIM-sized smartcards have 2048 bit keys and
the credit-card smartcards 1024 bit keys.
I find that rather ironic, as the credit-card sized smartcards are
advertised as slightly "more secure" by LuxTrust.
Just out of curiosity: how did you manage to do this,
how did you
(or Georges Bart) get the necessary information for this
development?
Georges Bart: I don't know. Me: Well, I spied on the communication
between the binary-only driver and the smartcard, and with the help of
some "leaked" parts of (an older version) of the ISO standard on
(crypto) smartcards, which the smartcard *partially* follows, I made
sense of the stream of bytes and configured my driver to do the same.
As Lilux, we have had contacts with Luxtrust (...)
Back then, they
agreed that _if_ a 64 bit driver was available from another source,
they would also follow with their libraries (... )
Great!
it might now be interesting to take up contact again.
Our emails on that crossed each other. Yes, by all means!
Btw, I had a peek in Gemalto's own drivers (using
a crude
decompiler), and apparently they heavily use OpenSC themselves...
They acknowledge that in their license / copyright file. However, they
do not obey OpenSC's license fully: they do not give us .o files for
their binary-only parts, so that we could relink it against a newer
version of OpenSC, which might actually make their binary-only driver
work on newer GNU/Linux systems (e.g. it does not work with Debian
"lenny" 5.0, only with Debian "etch" 4.0).
--
Lionel
4:57 p.m.
On 12/01/11 17:33, Lionel Elie Mamane wrote:
Interesting.
No Pb
Yes, noticed that too (... but only had noticed it _after_ I've already found
it out by other means...)
On Wed, Jan 12, 2011 at 03:15:38PM +0100, Alain Knaff
wrote:
ok... I guessed that much, but still wanted to be sure.
On 12/01/11 14:46, Lionel Elie Mamane wrote:
> I'm pleased to report that I've
developed a free software driver /
> middleware for LuxTrust-issued smartcards. Details at
> http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools
This is great news, congratulations! This is
useful not only for 64 bit
processors, but also for non-Intel Linux devices such as the Nokia N900.
I suppose this works both for the credit-card sized smartcards and for the
"signing sticks" (which take a SIM-sized chipcard)?
Yes. From the software POV, the SIM-sized smartcard and the
credit-card sized smartcard are identical; they present the same ATR. The only difference I could see is the size of the
keys on it; if
memory serves me right the SIM-sized smartcards have 2048 bit keys and
the credit-card smartcards 1024 bit keys.
I find that rather ironic, as the credit-card sized smartcards are
advertised as slightly "more secure" by LuxTrust.
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.
Just out of
curiosity: how did you manage to do this, how did you
(or Georges Bart) get the necessary information for this
development?
Georges Bart: I don't know. Me: Well, I spied on the communication
between the binary-only driver and the smartcard, and with the help of
some "leaked" parts of (an older version) of the ISO standard on
(crypto) smartcards, which the smartcard *partially* follows, I made
sense of the stream of bytes and configured my driver to do the same. As Lilux, we have had contacts with Luxtrust
(...) Back then, they
agreed that _if_ a 64 bit driver was available from another source,
they would also follow with their libraries (... )
Great!
it might now be interesting to take up contact
again.
Our emails on that crossed each other. Yes, by all means! Btw, I had a peek in Gemalto's own drivers
(using a crude
decompiler), and apparently they heavily use OpenSC themselves...
They acknowledge that in their license / copyright file. However, they
do not obey OpenSC's license fully: they do not give us .o files for
their binary-only parts, so that we could relink it against a newer
version of OpenSC, which might actually make their binary-only driver
work on newer GNU/Linux systems (e.g. it does not work with Debian
"lenny" 5.0, only with Debian "etch" 4.0).
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...
From what they explained to me, they did this because
the Java Crypto API (not
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
6:31 p.m.
On Wed, Jan 12, 2011 at 05:57:36PM +0100, Alain Knaff wrote:
On 12/01/11 17:33, Lionel Elie Mamane wrote:
> On Wed, Jan 12, 2011 at 03:15:38PM +0100, Alain Knaff wrote:
>> On 12/01/11 14:46, Lionel Elie Mamane wrote:
> Yes. From the software POV, the SIM-sized
smartcard and the
> credit-card sized smartcard are identical; they present the same ATR.
> The only difference I could see is the size of the keys on it; if
> memory serves me right the SIM-sized smartcards have 2048 bit keys and
> the credit-card smartcards 1024 bit keys.
> I find that rather ironic, as the credit-card
sized smartcards are
> advertised as slightly "more secure" by LuxTrust.
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.
Oh. Do you have details on that? Can one for example do that for
etat.lu websites (eTVA, RCSL, ...)? We may be interested to actually
do that for certain critical operations.
Moreover, Luxtrust provides a fraud insurance with
their media, and
the amount insured is higher for the credit cards than for the SIMs.
That's probably what I interpreted as "more secure"; if you are
willing to give a higher insurance, it means you consider it more
secure :)
>> Btw, I had a peek in Gemalto's own
drivers (using a crude
>> decompiler), and apparently they heavily use OpenSC themselves...
> However, they do not obey OpenSC's license
fully: they do not give
> us .o files for their binary-only parts, so that we could relink it
> against a newer version of OpenSC, which might actually make their
> binary-only driver work on newer GNU/Linux systems (e.g. it does
> not work with Debian "lenny" 5.0, only with Debian "etch" 4.0).
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).
I *think* it is actually Mozilla Firefox that I tested, but I'm not
100% sure; possibly it was openssl and/or some OpenSC part. The latter
might have been the source of my "does not work on newer system", as
Debian etch happens to have the same (or close) version of OpenSC as
included in libgemsafe, maybe they don't "fight" each other.
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...
They contradict, but not in extremely fundamental ways. OpenSC is
LGPL, so they are allowed to mix OpenSC and their own code, and
license the resulting binary under nearly any license. So it is not
like GPL, where they would have to give the source code of the whole
library, etc. Additionally to not providing the .o files as I already
mentioned:
- They have to allow some kinds of reverse-engineering, though, which
they failed to (sufficiently) do.
- They have to allow modifications for "one's own use", they don't.
I don't need to rely on that bit of the LGPL anyway, as what I did is
covered under article 5, paragraph 3 of Directive 2009/24/EC of the
European Parliament and of the Council of 23 April 2009 on the legal
protection of computer programs.
It seems relatively clear to me that they intend their EULA to apply
to the finished product, and the LGPL is there to apply to the
OpenSC-derived parts, and those *only*. So the LGPL does not take
precedence over the whole.
What about taking precedence in the restricted meaning that what the
LGPL *does* require over the whole (allow modifications for one's own
use, allow some reverse-engineering, ...) is actually granted to us
automatically? For this, I'll refer to
http://www.maitre-eolas.fr/post/2010/12/26/Lrsquo%3Baffaire-ldquo%3Bla-cart…
where Maître Eolas argues that it does not. He says that only the
copyright holders of OpenSC have standing to act against Gemalto's
LGPL violation, and still then not by simply taking the liberties
required by the LGPL over the binary-only parts. Only by requiring
Gemalto to cease and desist distributing libgemsafe, or get
compensation from them, or ...
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.
From what they explained to me, they did this because
the Java
Crypto API (not 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.
They could have avoided Java altogether ;-)
--
Lionel
13 Jan
13 Jan
10:54 p.m.
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
14 Jan
14 Jan
8:59 a.m.
On Thu, Jan 13, 2011 at 11:54:58PM +0100, Lionel Elie Mamane wrote:
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.
Actually, work to do that is already underway in
/branches/vtarasov/opensc-sm.trunk in their SVN. Excellent!
--
Lionel
25 Jan
25 Jan
10:50 a.m.
On 14/01/11 09:59, Lionel Elie Mamane wrote:
Yesterday, I tried to follow your instructions in
http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools , but
unfortunately the tools segfault:
On Thu, Jan 13, 2011 at 11:54:58PM +0100, Lionel Elie
Mamane wrote:
Two years ago, I started working on a disassembler, which might come in handy here.
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.
Actually, work to do that is already underway in
/branches/vtarasov/opensc-sm.trunk in their SVN. Excellent!
gdb /some/place/bin/pkcs15-tool
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:
strace -fo logg /some/place/bin/pkcs15-tool
--list-keys
Using reader with a card: Gemplus GemPC Key 00 00
zsh: segmentation fault strace -fo logg /some/place/bin/pkcs15-tool --list-keys
fgrep /lib/ logg | fgrep -v NOENT
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
1:22 p.m.
On 25/01/11 11:50, Alain Knaff wrote:
[...]
This segmentation fault not only happens on Ubuntu Lucid 64 bit, but also on
Lucid 32 bit, and on Lenny 32 bit.
alain@hitchhiker:~/Projects/Luxtrust/c3l-lenny/opensc$ gdb /some/place/bin/pkcs15-tool
GNU gdb 6.8-debian
Copyright (C) 2008 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 "i486-linux-gnu"...
(gdb) r --list-keys
Starting program: /some/place/bin/pkcs15-tool --list-keys
[Thread debugging using libthread_db enabled]
[New Thread 0xf73a86b0 (LWP 9315)]
Using reader with a card: Gemplus GemPC Key 00 00
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf73a86b0 (LWP 9315)]
0xf743b733 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xf743b733 in strlen () from /lib/libc.so.6
#1 0xf743b455 in strdup () from /lib/libc.so.6
#2 0xf7544b78 in sc_pkcs15_bind_internal (p15card=0x9764508,
aid=<value optimized out>) at pkcs15.c:706
#3 0xf75461ae in sc_pkcs15_bind (card=0x9764118, aid=0x0,
p15card_out=0x8051d48) at pkcs15.c:946
#4 0x0804c6c8 in main (argc=Cannot access memory at address 0x0
) at pkcs15-tool.c:1781
Any ideas?
Thanks,
Alain
gdb
/some/place/bin/pkcs15-tool
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
4:54 p.m.
On Tue, Jan 25, 2011 at 11:50:10AM +0100, Alain Knaff wrote:
Yesterday, I tried to follow your instructions in
http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools , but
unfortunately the tools segfault:
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
5:20 p.m.
On 25/01/11 17:54, Lionel Elie Mamane wrote:
On Tue, Jan 25, 2011 at 11:50:10AM +0100, Alain Knaff
wrote:
Thanks. With this, pkcs15-tool works great, but unfortunately not pkcs11-tool:
Yesterday, I tried to follow your instructions in
http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools , but
unfortunately the tools segfault:
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.
/some/place/bin/pkcs11-tool --list-slots
Available slots:
Slot 0 (0x0): (GetSlotInfo failed, CKR_ARGUMENTS_BAD)
Slot 1 (0x1): Gemplus GemPC Key 00 00
(empty)
Slot 2 (0x2): Gemplus GemPC Key 00 00
(empty)
Slot 3 (0x3): Gemplus GemPC Key 00 00
(empty)
Slot 4 (0x4): Virtual slot
(empty)
Slot 5 (0x5): Virtual slot
(empty)
Slot 6 (0x6): Virtual slot
(empty)
Slot 7 (0x7): Virtual slot
(empty)
Slot 8 (0x8): Virtual slot
(empty)
Slot 9 (0x9): Virtual slot
(empty)
Slot 10 (0xa): Virtual slot
(empty)
Slot 11 (0xb): Virtual slot
(empty)
Slot 12 (0xc): Virtual slot
(empty)
Slot 13 (0xd): Virtual slot
(empty)
Slot 14 (0xe): Virtual slot
(empty)
Slot 15 (0xf): Virtual slot
(empty)
/some/place/bin/pkcs11-tool --slot-index 1 -l -O
Using slot with index 1 (0x1)
error: PKCS11 function C_OpenSession failed: rv = CKR_TOKEN_NOT_PRESENT (0xe0)
Aborting.
Any ideas?
Thanks,
Alain
6:14 p.m.
On 01/25/2011 06:20 PM, Alain Knaff wrote:
On 25/01/11 17:54, Lionel Elie Mamane 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 Tue, Jan 25, 2011 at 11:50:10AM +0100, Alain
Knaff wrote:
Thanks. With this, pkcs15-tool works great, but unfortunately not pkcs11-tool: Yesterday, I tried to follow your instructions in
http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools , but
unfortunately the tools segfault:
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.
7:15 p.m.
On Tue, Jan 25, 2011 at 06:20:44PM +0100, Alain Knaff wrote:
On 25/01/11 17:54, Lionel Elie Mamane wrote:
> On Tue, Jan 25, 2011 at 11:50:10AM +0100, Alain Knaff wrote:
>> Yesterday, I tried to follow your instructions
in
>> http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools , but
>> unfortunately the tools segfault:
> 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.
Thanks. With this, pkcs15-tool works great, but
unfortunately not
pkcs11-tool:
/some/place/bin/pkcs11-tool --list-slots
Available slots:
Slot 0 (0x0): (GetSlotInfo failed, CKR_ARGUMENTS_BAD)
Slot 1 (0x1): Gemplus GemPC Key 00 00
(empty)
Slot 2 (0x2): Gemplus GemPC Key 00 00
(empty)
Slot 3 (0x3): Gemplus GemPC Key 00 00
(empty)
/some/place/bin/pkcs11-tool --slot-index 1 -l -O
Using slot with index 1 (0x1)
error: PKCS11 function C_OpenSession failed: rv = CKR_TOKEN_NOT_PRESENT (0xe0) From what I experimentally observed, pkcs11-tool does
not load a
PKCS#11 module/middleware by default, but does not clearly say so. You
need to tell it to load the OpenSC PKCS#11 module (or the Gemalto
binary-only one, if that's what you want), just like the Mozilla
applications. It is as stupid as that :)
Try adding "--module=/opensc/prefix/lib/opensc-pkcs11.so".
--
Lionel
9:04 p.m.
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:
From what I
experimentally observed, pkcs11-tool does not load a
PKCS#11 module/middleware by
default, but does not clearly say so. You
need to tell it to load the OpenSC PKCS#11 module (or the Gemalto
binary-only one, if that's what you want), just like the Mozilla
applications. It is as stupid as that :)
Try adding "--module=/opensc/prefix/lib/opensc-pkcs11.so".
time /some/place/bin/pkcs11-tool --slot 1
--module=/some/place/lib/opensc-pkcs11.so -t -l
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:
time /some/place/bin/pkcs11-tool --slot 1
--module=/some/place/lib/opensc-pkcs11.so -t -l
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
10:28 p.m.
On Tue, Jan 25, 2011 at 10:04:48PM +0100, Alain Knaff wrote:
On 01/25/2011 08:15 PM, Lionel Elie Mamane wrote:
> Try adding
"--module=/opensc/prefix/lib/opensc-pkcs11.so".
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?
Use of the cache is not enabled by default in SVN version (some
distros seem to have it enabled it by default in their packaged
versions), and in all versions never silently populated. So:
Enable it in /opensc/prefix/etc/opensc.conf and run
pkcs15-tool -L
to populate it.
Then, things should be *much* faster indeed.
Another strange thing:
time
/some/place/bin/pkcs11-tool --slot 1 --module=/some/place/lib/opensc-pkcs11.so -t -l
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;
It aborts when you try to use the signature key, which my driver is
unable to use: the card requires the command to be cryptographically
signed in some way I haven't cracked yet.
The error code given by the card is the same as if the PIN had not
been given, which explains the error message you get. The error code
is the one for "security status not satisfied", which can mean any of:
- no PIN given
- a PIN successfully given, but that PIN does not allow using that
key; a card can have several PINs that unlock the same or
different keys.
- the command needs to be cryptographically signed (our case)
- the data the card is asked to operate on is not formatted correctly
(e.g. wrong padding, not validly ASN.1 BER encoded, ...)
- possibly the card refuses to use that key with that algorithm
(e.g. with MD5)
I guess that PIN problems are by far the most common occurrence, at
least when the driver is complete and bug-free, so that very generic
error is mapped to the "the needed PIN has not been given" user-level
error. <shrug>
--
Lionel
26 Jan
26 Jan
7:16 a.m.
On 01/25/2011 11:28 PM, Lionel Elie Mamane wrote:
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?
Use of the cache is not enabled by default in SVN
version (some
distros seem to have it enabled it by default in their packaged
versions), and in all versions never silently populated. So:
Enable it in /opensc/prefix/etc/opensc.conf and run
pkcs15-tool -L
to populate it.
Then, things should be *much* faster indeed.
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?
[...]
Why does it
say CKR_USER_NOT_LOGGED_IN? My pin was correct;
It aborts when you try to use the signature key, which my driver is
unable to use: the card requires the command to be cryptographically
signed in some way I haven't cracked yet.
The error code given by the card is the same as if the PIN had not
been given, which explains the error message you get. The error code
is the one for "security status not satisfied", which can mean any of:
- no PIN given
- a PIN successfully given, but that PIN does not allow using that
key; a card can have several PINs that unlock the same or
different keys.
- the command needs to be cryptographically signed (our case)
ok, I see.
- the data the card is asked to operate on is not formatted correctly
(e.g. wrong padding, not validly ASN.1 BER encoded, ...)
- possibly the card refuses to use that key with that algorithm
(e.g. with MD5)
Well, the first 3 seem to be related, but for these last 2, they really
should have used a different error code.
I guess that PIN problems are by far the most common occurrence, at
least when the driver is complete and bug-free, so that very generic
error is mapped to the "the needed PIN has not been given" user-level
error. <shrug>
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
8:14 a.m.
On Wed, Jan 26, 2011 at 08:16:17AM +0100, Alain Knaff wrote:
On 01/25/2011 11:28 PM, Lionel Elie Mamane wrote:
> Use of the cache is not enabled by default in SVN
version (some
> distros seem to have it enabled it by default in their packaged
> versions), and in all versions never silently populated. So:
> Enable it in /opensc/prefix/etc/opensc.conf and
run
> pkcs15-tool -L
> to populate it.
> Then, things should be *much* faster indeed.
Maybe, it would be a good idea to add that info (and
your patch to fix
the NULL label bug) to the wiki page?
Yes. Feel free to do it :)
>> Why does it say CKR_USER_NOT_LOGGED_IN? My pin
was correct;
> It aborts when you try to use the signature key,
which my driver is
> unable to use: the card requires the command to be cryptographically
> signed in some way I haven't cracked yet.
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...
Maybe we could sit down together some day in the next weeks and take a
look at it. An approach would be to use a debugger with a breakpoint
to the point where it sends data to pcscd, and then try to go up the
call stack / back the instruction stream and see "what it does" just
before. With a disassembler, it is manual work, but possibly doable?
And surely there are off-the-shelf free software disassemblers we can
use. (I mean a disassembler as opposed to a decompiler.) Sure, a
decompiler would make things easier, but we do with what we have.
But we need to find out not only the _key_, but also the algorithm :)
Possibly the key is "just" the PIN? Or maybe a true hardcoded (in the
driver) cryptographic key. I don't know.
Or is it that the "normal" commands are not
signed at all?
Normal commands are not signed at all. You give the PIN once in a
separate command, and then you can use any "other" PIN-protected
command, until the card is reset (either physically or through a
"reset" command).
--
Lionel
9:22 a.m.
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...
[...]
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
On Wed, Jan 26, 2011 at 08:16:17AM +0100, Alain Knaff
wrote:
[...]
Maybe, it
would be a good idea to add that info (and your patch to fix
the NULL label bug) to the wiki page?
Yes. Feel free to do it :) Maybe we could sit down together some day in the next
weeks and take a
look at it.
Good idea. The next 3 weeks, I'm somewhat busy, but starting from mid of
February my availability is better.
An approach would be to use a debugger with a
breakpoint
to the point where it sends data to pcscd, and then try to go up the
call stack / back the instruction stream and see "what it does" just
before. With a disassembler, it is manual work, but possibly doable?
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.
And surely there are off-the-shelf free software
disassemblers we can
use.
Disassemblers, yes (such as objdump). I used objdump in my decompiler, and then
postprocess its output.
(I mean a disassembler as opposed to a decompiler.)
... 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...
Sure, a
decompiler would make things easier, but we do with what we have.
But we need to find out not only the _key_, but also the algorithm :)
possibly, the symbols might give hints... It calls opensc in lots of places...
Possibly the key is "just" the PIN? Or maybe
a true hardcoded (in the
driver) cryptographic key. I don't know.
When I'll have more time, I'll have a look at the "decompiled" code,
to see
whether I can find anything...
Or is it that the "normal" commands are
not signed at all?
Normal commands are not signed at all. You give the PIN once in a
separate command, and then you can use any "other" PIN-protected
command, until the card is reset (either physically or through a
"reset" command).
11:11 a.m.
On Wed, Jan 26, 2011 at 10:22:41AM +0100, Alain Knaff wrote:
On 26/01/11 09:14, Lionel Elie Mamane wrote:
> An approach would be to use a debugger with a
breakpoint
> to the point where it sends data to pcscd, and then try to go up the
> call stack / back the instruction stream and see "what it does" just
> before. With a disassembler, it is manual work, but possibly doable?
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)?
Not necessarily, but it is the way OpenSC does it; if the card is not
PKCS15-compliant, it adds a card-specific emulation layer to present
a PKCS15 interface to the rest of the OpenSC code.
As libgemsafe uses OpenSC, I guess they inherited this architecture.
If so, where would this encryption happen? In the
PKCS11 front-end,
or in the back end?
As our luck would have it, the command is not encrypted; there is just
some kind of "cryptographich hash" appended to it; I'll show my pcscsd
dumps when we get together. That's what I called "signed".
I'd say it definitely happens in the back-end; my money is on the
Gemsafe "thingy".
Interesting symbols:
vtable for SCU::SecureMessagingSSCFilter
SCU::SCUBase::GetSecureMessageKeys_
SCU::SCUGemSafeV2Internal::GetSecureMessageKeys_
SCU::SCUGemSafeVx<SCU::SCUGemSafeV2Internal>::GetSecureMessageKeys
SCU::SecureMessagingSSCFilter::ComputeMACApdu
SCU::SecureMessagingSSCFilter::SetInitializeMode
SCU::SecureMessaging::retail_MAC
in libSCU.so
Also, PKCS11 has lots of API entry points... which API
function
needs the additional encryption?
You are looking at it at too high a level; the answer would be:
C_SignInit/C_Sign/C_SignUpdate/C_SignFinal, but only when used with
the signature key, not when used with the authentication key.
As far as I understand there is one function that
needs it, and
another one, which is quite similar, which doesn't need it.
No, it is the same function, but depending on the *parameters*, one
has to use "Secure Messaging" (that is, signed commands to the card)
or not.
I guess that the flag that means that key needs signed command is:
Access: always authenticate (PKCS11)
> And surely there are off-the-shelf free software
disassemblers we
> can use.
> (I mean a disassembler as opposed to a
decompiler.)
... yes, but unfortunately we'd pretty much need
a decompiler, in
order to be able to make sense out of it...
I'd have imagined that with a working knowledge of x86 assembly (which
I don't have, but an occasion to learn...), one can follow what the
code does :)
> But we need to find out not only the _key_, but
also the algorithm :)
possibly, the symbols might give hints... It calls
opensc in lots of
places...
More interestingly, it calls the following algorithms of OpenSSL:
MD5
SHA1
DES/3DES
RSA
The "signature" is 64 bits long... Far too short for anything RSA;
That *could* be a truncated MD5/SHA1 (keyed / Message Authentication
Code) hash, but my best guess is:
- MD5/SHA1/RSA is called only to do in software what makes no sense
to do on the card.
- DES/3DES is used to sign the command! It fits, 64 bits is the block
size of DES.
>> Or is it that the "normal" commands
are not signed at all?
> Normal commands are not signed at all. You give
the PIN once in a
> separate command, and then you can use any "other" PIN-protected
> command, until the card is reset (either physically or through a
> "reset" command).
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?
As far as I understand, when app A disconnects (from pcscd), pcscd
resets the card. Possibly pcscd also refuses to allow "context
switching" between apps without a reset in between, but I don't think
so, unless the app requests exclusive access. Anyway, the OpenSC docs
very clearly say that this is a danger (one app gives PIN, other app
uses key), unless it is configured to lock the card.
--
Lionel
12 Jan
12 Jan
3:51 p.m.
On Wed, Jan 12, 2011 at 02:46:39PM +0100, Lionel Elie Mamane wrote:
I'm pleased to report that I've developed a
free software driver /
middleware for LuxTrust-issued smartcards. Details at
http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools
From the April 2010 archives of this mailing list, it
seems that you
already had contact with LuxTrust over usage of their smartcards with
GNU/Linux on non-i386 platforms.
Maybe you could reactivate the same contacts and nudge them in the
direction of using the same web/open standard way of authenticating
with their website than the etat.lu / public.lu / guichet.lu?
The web/open standard way is to ask for presentation of the
certificate at the SSL/TLS layer, and let the browser ask the user
which certificate to present.
This would allow their website to work with my driver.
--
Lionel
5603
days inactive
5617
days old
19 comments
2 participants
participants (2)
-
Alain Knaff -
Lionel Elie Mamane