Hi Andreas,
I checked out your trunk from svn and changed the if statement to this:
/* for cardos cards initialized by Siemens or PrimeKey: sign with
decrypt */
if (strcmp(p15card->card->driver->short_name,"cardos") == 0
&& ( strcmp(p15card->manufacturer_id,"Siemens AG (C)") == 0 ||
strcmp(p15card->manufacturer_id,"Prime") == 0 ))
p15card->flags |= SC_PKCS15_CARD_FLAG_SIGN_WITH_DECRYPT;
This is working fine for me. I will be happy if you commit this change to SVN.
"SHA1withRSAandMGF1" is a signing algorithm where the most significant byte of
the padding is not 0. The command send to the card with response is
looking like this for this algorithm:
APDU: 00 2A 80 86 00 01 01 00 56 E7 FC 3E 40 4C 37 28 53 90 0A 1B 4E FB 7B 87
0A 8D 00 F6 5E 80 D3 10 5C 66 D6 0F 3F FB 9D 9E D8 B8 52 4E B3 D4 A1 62
3C FB 42 D5 FC B2 D4 9A 54 A4 66 64 8F 19 7B 6B DE 84 F4 4B B2 B2 6E 4D AE CB
9C 09 00 B2 39 33 C3 BB D9 43 02 47 DA C0 EE C8 A5 D1 5B C1 2B AA 4F 14
3E FC 93 84 45 06 D5 2E 2C AF 00 B5 A1 85 59 71 C2 2C 1F 9E DF DA 1F 59 1E 78
EB A6 3E 8D EC C8 83 7D BD 0F 59 6D 47 56 6E 55 9A 0C 85 9C D5 7C BE C7
30 94 66 B0 BC 86 2F E5 5A 2A 17 84 9F 1F 20 9D C2 A7 BD 1C C4 51 BB 2A AA 14
2B 29 D4 0C 23 87 16 AD E0 7E 40 56 78 BF 82 BA E4 98 BA 4A CF F6 2B 89
34 3C C0 BC AF C2 0A F6 16 F1 31 40 B6 9F 14 D9 25 F1 13 19 A4 B9 21 55 C8 DD
F1 CD A7 E4 90 84 74 2A 1B 94 CF D8 B5 A9 94 62 19 B9 53 AD 68 35 AB 62
F3 2D 58 6E 09 81 72 2E 13 4F 64 7D E3 35 96 BC 00 00
SW: 90 9E 10 DA E9 E1 92 5C A7 FE EA F2 05 5B E3 CF 6D FA E8 53 1E 7C 91 0E B4
92 FA 1F 1A 4D 0D 0C 86 38 C2 A9 EE 90 0B 3D C5 DF 00 44 85 A2 A3 7A 58
93 E4 3A 6E 22 DB 94 7C 90 5A 9E 76 08 BA 59 92 1D 11 37 2D 8F 21 66 64 CE E4
83 78 57 19 55 13 3A D5 51 2D 44 C7 25 F5 CB 8B D0 BE F8 F7 C5 2F 1E F6
D2 65 01 54 C6 54 00 85 15 16 DD 9D 6C 73 9C 63 76 2D 00 43 A8 88 4D 04 FB 4B
57 F6 55 37 E9 6A 23 51 03 1E 42 59 7A 3F A9 7C 13 91 2B 2A 30 BC D0 AD
2F C3 97 32 A1 07 41 64 C0 2F 7D 15 69 DC 61 CD 3E 8B 99 4F 04 82 CA A1 BB 5C
85 22 A2 C3 32 DB 33 1D 8D 05 19 77 14 7C 25 2E 80 B8 13 B8 33 9D 99 FA
74 2D AA A1 79 49 11 BE DD 59 76 8C 3A F8 02 00 7F F0 F1 7A 72 C1 59 2F 02 28
73 77 8E E2 27 0F 0E 39 F7 4C 3B 14 EE 4E CF D2 3D 1E 73 90 AC 47 0E AF
F9 8D 4C 3F C7 DF 96 90 00
You can see the the most significant byte for the RSA operation is 0x56 (257
bytes is sent to the card and the first that is 0 will not be used). If
you want any MGF1 algorithm the signing command can not be used. We don't want
any unnecessary restrictions on the cards that are issued. You never
know what they will be used for in the future. We have a java crypto provider
that supports MGF1 signings with our cards.
Does "storing the same key twice" means that you don't generate the key on the
card?
I will send some cards for you with different profiles next week.
Cheers,
Lars
Andreas Jellinghaus wrote:
> 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
