26 Jan
2011
26 Jan
'11
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).