On 14/01/11 09:59, Lionel Elie Mamane wrote:
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.
Two years ago, I started working on a disassembler, which might come in handy here.
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!
Yesterday, I tried to follow your instructions in
http://c3l.lu/wiki/index.php/Luxtrust#Using_Open_source_tools , but
unfortunately the tools segfault:
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