Oops, I was mistaken in my previous note, the prefix is sent to be signed.
Thunderbird with NSS calling opensc-pkcs11 for RSA 2048 bit key:
1322: C_Sign
[in] hSession = 0xf1a2d160
[in] pData[ulDataLen] f24f9010 / 35
30213009 06052B0E 03021A05 0004145C 1362A567 70C3E95E 0B5881B8 5AA257BC
081B20
debug output of the chained sign operation:
Outgoing APDU data [ 260 bytes] =====================================
10 87 07 9C FF 7C 82 01 06 82 00 81 82 01 00 00 .....|..........
01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 ............0!0.
06 05 2B 0E 03 02 1A 05 00 04 14 5C 13 62 A5 67 ..+........\.b.g
70 C3 E9 5E p..^
======================================================================
Outgoing APDU data [ 17 bytes] =====================================
00 87 07 9C 0B 0B 58 81 B8 5A A2 57 BC 08 1B 20 ......X..Z.W...
00 .
======================================================================
This is verified on another system.
On 12/14/2010 10:54 AM, Douglas E. Engert wrote:
>
>
> On 12/14/2010 5:29 AM, Martin Paljak wrote:
>>
>> On Dec 14, 2010, at 1:21 PM, Andre Zepezauer wrote:
>>
>>> On Tue, 2010-12-14 at 13:07 +0200, Martin Paljak wrote:
>>>>
>>>> Right now I guess that the stripping of input data, coming from an
>>>> application (meaning that the calling application will expect the data to
>>>> be exactly the same when verifying the signature) is wrong in pkcs15-sec.c
>>>> [1].
>>>> As there are no other fields that would control the absence (or addition
>>>> in the card) of DigestInfo prefix, it does not make any sense to me.
>>>> Thoughts anyone?
>>>
>
> If I am not mistaken, the prefix is not part of the hash, and should not be
> signed.
> So the question is why is the prefix being passed in here at all?
> Is this code really used with any current cards?
>
> Is this some issue with using OpenSSL for hashing, and the prefix was left on?
>
>>> It really does make sense for cards, that will reattach the prefix
>>> internally ;)
>>
>> Do you know such cards (other than D-trust CardOS cards)? How to signal such
>> behavior to the card and inside libopensc?
>
> Two cards, card-cardos.c and card-incrypto34.c also call the
> sc_pkcs1_strip_digest_info_prefix. so may take care of this internally.
>>
>>
>
>
>
> In the note from Stef [2] it says:
> - While I think ISO's RSA SHA1 PKCS#1 means
> ASN1-ENCODE + PKCS1-PAD + RSA
>
> That does not make sense, as there is no hash being done, so why
> would it have _SHA1_ in the name?
>
> The nore is from 2002, so may have been fixed or addressed in some other way.
>
> [2]
> http://www.opensc-project.org/pipermail/opensc-devel/2002-December/000340.html
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
