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