Hello,
we still have the problem with our PKCS#11 module at verification of signed
mails.
We already had some conversation with Robert Relyea which I paste at the end
of this message for all to understand our problem. The following text can be
seen as an response to Roberts last mail.
Focusing on the Padding Problem I tried some Szenarios to find the exact error. First I tried to sign something with our card without using Mozilla. I could verify the resulting signature with OpenSSL successfully.
After that I included the Bouncycastle Provider on the Java-Side of my
module to do some signing with the messageDigest Mozilla gave me but
using the software keys instead of the smartcard (same keys of course)..
First I tried a simple SHA1WithRSA signing which resulted in completely
different and still not verifiyable signatures as with using the
smartcard, as I expected. After that I used the RSA/ECB/PKCS1Padding
encryption Algorithm which resulted in the same data as the card signing
does. The same happend when I build the PKCS#1 Padding by hand and use
the RSA/ECB/NoPadding Algorithm. Decrypting the signatures (software and
card versions) with RSA/ECB/NoPadding resulted in a bytearray of only
127 byte length . Checking the content revealed, that the leading '0' is
missing . Using RSA/ECB/PKCS1Padding for decrytion resulted in the same
35 byte long bytearray, mozilla passes to the C_Sign funktion.
After that I'm quiet sure, that the padding of our smartcard proxy is correct
or at
least it is the same as RSA/ECB/PKCS1Padding. The results returned at
the C-Side (passed to mozilla) are the same as produced at the Java-Side
(besides the unsinged / signed conversion).
I have no idea what can still be wrong. Is RSA/ECB/PKCS1Padding the
wrong Algorithm?
As the padding seems to be correct, do You have any other suggestions what could be wrong?
thanks in advance
greetings
Christopher
previous messages:
>>
>>Christopher Ritter wrote on Mon, 10 May 04, 6:05 AM:
>>
>>
>
>>>>We have problems on the signing side:
>>>>
>>>>- Our cards support a signing operation with a private key.
>>>>
>>>>- Mozilla can�t verify the signed mails and says that the signature is
>>>>invalid.
>>>>
>>>>- We have a logging mechanism which shows us the pkcs#11 operations and
>>>>its parameters.
>>>>
>>>>- Mozilla calls C_FindObjectsInit-method just asking for a CKA_VALUE,
>>>>this value seems not to match with one of our Objects. Do You know which
>>>>object could be requested by mozilla?
>>>>
>>>>
>
>>
>>Off the top of my head, the only thing we are likely to ask for by value is
the certificate. NSS is trying to match a private key to the certificate it found. What is the Value being asked (is it between 500-1000 bytes or is it 20 bytes or something very round like 128 bytes?).
>> >> >> > >>>>- If we give (in the above case) mozilla the signing certificate, >>>>signing seems to work, but the signature can not be verified. >>>> >>>>- We used an ASN.1 converter to observe the signed mail. It seems that >>>>the messageDigest in that file is different from the one we get in the >>>>C_Sign-method. >>>> >>>> > >> >>Are you doing the PKCS #1 formatting? NSS will pass an ASN.1 encoded
messageDigest package. This package must be wrapped in an PKCS #1 signature value.
>>
>>
>>
>
>>>>- Mozilla asks for the modulus of the private key, we give it the
>>>>modulus of the public key, which should be the same. Can You tell us for
>>>>what mozilla is using the modulus? (We are not sure if our conversion
>
>>>from the Java BigInteger Class to the C side CK_BYTE is correct.) Do You
>
>>>>know how mozilla represent the modulus)
>>>>We can give it a 129 Byte 2's Complement or a 128 Bytes 2's Complement
>>>>without a Signum.
>>>>
>>>>
>
>>
>>I'd have to check the code, but I believe NSS is trying to find out the key
length so it knows how much data to allocate to accept the result. In anycase
PKCS #11 modules are supposed to return 128 byte unsigned values (in this
case the high bit is '1' for a normal modulus). NSS accepts 129 byte 2's
complement as well.
>>
>>
>>
>
>>>>We tried to verifiy the mail with openssl, this programm tells us that
>>>>the blocksize of the signed mail is incorrect (not 01),. Can You tell us
>>>>what this could meant, or is there a case where we have to set the
>>>>blocksize in the pkcs#11 module?
>>>>
>>>>
>
>>
>>It definately sounds like you aren't wrapping the messageDigest with PKCS #1.
>>
>>bob
---------------
Hello,
thanks for your reply.
After fixing a tiny bug in my implementation I'm finaly able to validate, that NSS is asking for the Certificate when caling C_FindObjectInit with just the CKA_VALUE Field. With this I know that Mozilla is getting the correct objecthandles for the Signature Certificate and after asking for the ID it gets the corresponding private_key objecthandle.
As for the messageDigest I�m not shure what You mean with PKCS#1 wrapping. What we get from Mozilla is a 35 Byte long Value where the first 15 Bytes match the SHA-1 identifier. So what I do is cut off the first 15 Bytes, convert the leftover 20 Bytes to an String representing the Hex-Values of the Bytes (to make sure nothing goes wrong on transmission) and pass them to my Java-Server. On the Java-Side I reconvert the "HEX-String" to a bytearray (using ByteArrayOutputStream) which unfortunatly has to be signed, since Java does not support any unsigned bytearrays. Our SmartCardProxy supports a sign method which gets an SHA-1 messageDigest (20 byte) and returns an (signed) bytearray with an BER encoded signature (128 byte). Is the BER encoding a problem? After byte-> hex and hex->byte conversion the unsinged values an the C-Side do exactly match the signed values on the Java-side (negative values converted of course) . The signature and its length (128 byte) are passed as return vlaues of the C_Sign Funktion.
Somethong wrong so far ?
So the modulus is the only part I can not validate. The size is correct, so if NSS is only looking for the length, everything should work fine. So I don�t think my conversion of the modulus is correct : On the java-side the modulus is of type BigInteger. To get a bytearray I just use the BigInteger.toByteArray method, getting a 129 byte long bytearray. For the transmission I use the same byte->hex and hex->byte conversion I already used for all the other data (certificates, messageDigest, un-/ wrapped key a.s.o.) . At the C-side I use the CK_BYTE type for the modulus, filling the fields from 0 to modulusSize with the values byteReceived[i].Hex2Int() where i = 0...receivedCount (which equals modulusSize). The first byte (modulus[0]) is 0 . (shouldn this be 1 ?)
Using the 129 byte bytearray the signature block in the ASN.1 viewer program does not look correct. Beginning with the 70 byte more than every second byte is zero
4595 30 13: SEQUENCE {
4597 06 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
4608 05 0: NULL
: }
4610 04 128: OCTET STRING
: 28 EF AE 03 20 74 65 73 74 20 31 31 31 00 69 6E
: 64 6F 77 73 3B 20 55 3B 20 57 69 6E 64 6F 77 73
: 20 4E 54 20 35 2E 30 3B 20 65 6E 2D 55 53 3B 20
: 72 76 3A 31 2E 36 29 20 47 65 63 6B 6F 2F 32 30
: 30 34 30 31 31 33 00 00 4C 00 20 00 34 00 2E 00
: 30 00 31 00 20 00 54 00 72 00 61 00 6E 00 73 00
: 69 00 74 00 69 00 6F 00 6E 00 61 00 6C 00 2F 00
: 2F 00 45 00 4E 00 22 00 00 00 22 00 3E 00 00 00
: }
: }Using the 128 byte bytearray (just cut the first field).there did never appear this mutch zero values. Neither case leads to a successfull verification.
Changing the modulus size also changes the size of this field (to exactly the size of the modulus), thats why I believe it is the signature.
As for the Error we got from openssl our last mail had an error: it�s not wrong blocksize, it is wrong block type ( block type not 01).
Perhaps You can see some mistakes I made.
thanks again
Christopher Ritter
-----
>>Ah!! OK we have a fundamental problem here. >> >>RSA signatures 101: >> >>The RSA algorithm only operates on blocks of modulus size, So an RSA
encryption or RSA signature will result in a block that is the same size as
the modulus. In order to create the correct input with the correct size, RSA
defines a padding method call PKCS #1. The PKCS #1 standard defines the
padding for both encryption and signature. I'll only talk about signatures.
You can find the full spec at http://www.rsalabs.com . The actual full
algorith is described as EMSA-PKCS1-v1_5 in that spec.
>>
>>A signature is padded as follows:
>>
>>0x00 || 0x01 || Pad || 0x00 || Signature Data
>>
>>where || is concatenation. Pad is 0 or more 0xff values set to fill the size
of the output to the length of the modulus. Example, a 512 bit key would typically create a signature as follows:
>>
>> 0x00, 0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>> 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>> 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>> 0xff, 0xff, 0xff, 0x00, sb00, sb01, sb02, sb03,
>> sb04, sb05, sb06, sb07, sb08, sb09, sb10, sb11,
>> sb12, sb13, sb14, sb15, sb16, sb17, sb18, sb19,
>> sb20, sb21, sb22, sb23, sb24, sb25, sb26, sb27,
>> sb28, sb29, sb30, sb31, sb32, sb33, sb33, sb34,
>>
>>Where sb00-sb34 is 35 bytes of signature data.
>>
>>The signature data is DER encoded data as shown below:
>>
>>DigestInfo ::= SEQUENCE {
>> digestAlgorithm AlgorithmIdentifier,
>> digest OCTET STRING
>>}
>>
>>In practice it would look like:
>>MD2: (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 02 05 00 04 10 || H.
>>MD5: (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10 || H.
>>SHA-1: (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H.
>>SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 || H.
>>SHA-384: (0x)30 41 30 0d 06 09 60 86 48 01 65 03 04 02 02 05 00 04 30 || H.
>>SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 || H.
>>
>>When an RSA signature is verified, the following is checked:
>>1) the encoding is an RSA PKCS #1 v1.5 signature (bytes 0 & 1 are 0x00,
0x01).
>>2) the padding is correct (bytes 2-n are either 0xff or 0x00. The first 0x00
is presumed to make the begining of signature data.
>>3) DerDecode the result to find the algorithm ID and the hash value. The hash
value must match the expected hash value carried elsewhere in the protocol.
>>
>>So the two errors you seem to be running into are: 1) The signature is not
wrapped in PKCS #1 and 2) the signature does not have the correct DER data.
>> >>You will need to find an interface that will either: 1) take a hash and
algorith value as separate parameters, or 2) take a the full 35-byte DER data
NSS passes you and wraps it with PKCS #1 v1.5, or 3) a raw rsa operation with
the private key in which you pass hand wrap the 35-byte DER data with PKCS #1
v1.5.
>>
>>bob
>>
>>
>>
>
>>>>So the modulus is the only part I can not validate. The size is correct,
>>>>so if NSS is only looking for the length, everything should work fine.
>>>>So I don�t think my conversion of the modulus is correct :
>>>>On the java-side the modulus is of type BigInteger. To get a bytearray I
>>>>just use the BigInteger.toByteArray method, getting a 129 byte long
>>>>bytearray. For the transmission I use the same byte->hex and hex->byte
>>>>conversion I already used for all the other data (certificates,
>>>>messageDigest, un-/ wrapped key a.s.o.) . At the C-side I use the
>>>>CK_BYTE type for the modulus, filling the fields from 0 to modulusSize
>>>>with the values byteReceived[i].Hex2Int() where i = 0...receivedCount
>>>>(which equals modulusSize).
>>>>The first byte (modulus[0]) is 0 . (shouldn this be 1 ?)
>>>>
>>>>
>
>>
>>If your modulus is 129 bytes long with a leading '0' you can simply drop the
leading '0' and have a 128 byte unsigned value. (first byte should have the high bit on ( 0x8X, 0x9X, 0xaX, 0xbX, 0xcX, 0xdX, 0xeX, 0xfX).
>>
>>NSS will handle pkcs #11 modules that export values as signed values with
leading '0's, but the PKCS #11 spec says these values should be unsigned, so
I would suggest converting to unsigned just for compliance.
>> >> _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
