Hi Lars,
thanks for your work. but we already have a different hack for cardos
initialized with siemens highpath.
in pkcs15.c in sc_pkcs15_bind_internal() we do this:
/* for cardos cards initialized by Siemens: sign with decrypt */
if (strcmp(p15card->card->driver->short_name,"cardos") == 0
&& strcmp(p15card->manufacturer_id,"Siemens AG (C)") == 0)
p15card->flags |= SC_PKCS15_CARD_FLAG_SIGN_WITH_DECRYPT;
not a nice hack, but it works for now. and in pkcs15-sec.c in
sc_pkcs15_compute_signature we check:
/* some strange cards/setups need decrypt to sign ... */
if (p15card->flags & SC_PKCS15_CARD_FLAG_SIGN_WITH_DECRYPT) {
size_t tmplen = sizeof(buf);
if (flags & SC_ALGORITHM_RSA_RAW) {
return sc_pkcs15_decipher(p15card, obj,flags,
in, inlen, out, outlen);
}
if (modlen > tmplen) {
sc_error(ctx, "Buffer too small, needs recompile!\n");
return SC_ERROR_NOT_ALLOWED;
}
r = sc_pkcs1_encode(ctx, flags, in, inlen, buf, &tmplen,
modlen)
;
/* no padding needed - already done */
flags &= ~SC_ALGORITHM_RSA_PADS;
/* instead use raw rsa */
flags |= SC_ALGORITHM_RSA_RAW;
SC_TEST_RET(ctx, r, "Unable to add padding");
r = sc_pkcs15_decipher(p15card, obj,flags, buf, modlen,
out, outlen);
return r;
}
..
sure, this approach can be improved. I hope the code is somehow readable?
basically we check for cardos and "Siemens" as manufacturer (info in the
pkcs15 data), and then set a flat. and in the high level signing function we
check for that flag, and either call decrypt directly (for raw signatures),
or manually add pkcs#1 padding and then call decrypt.
it works for me - I used a card initialized with siemens highpath software and
with this code I could run "pkcs11-tool --test --login" and pkcs15-crypt based
tests with success.
> The patch make it possible to sign with keys on CardOS cards that was
> generated to use only the decryption card command. This is because you can
> not generate keys on CardOS that accepts both the sign and decryption
> commands.
yes. we solved that by storing the same key twice with different flags.
siemens solved it by using decryption for signing. opensc can now use both
on initialized cards.
> Even when a key only should be used for signing it could be preferable to
> use the decryption command.
in general no. some cards allow only signing i.e. require padding, and the key
can't be used for raw rsa.
> This is when you use a padding where the MSB in
> the RSA input differs 0 in the input (of modulus length) to the RSA
> algorithm.
ok, I have little clue about the different paddings and how they exactly work.
what kind of padding does that? or does it depend on the key? is it handled
by our code or do we need extras for this? how can I create a situation like
this? (CC: to Nils added, he knows all this much better than I do.)
> All CardOS keys created by PrimeCard (see
> http://primekey.se/primekey/en/Products/PrimeCard.html) are keys where only
> the decrypt card command could be used. But some of these keys are intended
> only for signing.
could you use svn to check out current trunk code, extend the hack in pkcs15.c
to cover primekey cards as well and tell me if it works? if yes, we could add
this now and then discuss what the proper long term solution would be.
> I will be happy to send PrimeCard issued cards to those of you that will
> test and add this patch to opensc as well as to maintainers of the project.
> Just give me the mailing addresses.
well, I'm always happy to have additional cards for testing :)
Andreas Jellinghaus, Vogelhartstr. 17, 80807 Munich, Germany
adding +1 and -1 all over the place is a dirty hack. If it is possible the try
a solution similar to what we have, I would very much prefer that.
Regards, Andreas
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
