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