From: Joerg K. <joe...@we...> - 2016-02-21 09:54:09
|
Thanks for your quick reply! I would also have thought that if this is a general issue with the card it would have shown up a long time ago... But if I understood your comment correctly it is really "just" a missing leading zero, right? In that case it would be relatively straight forward and a valid workaround to detect and correct this from opensc without introducing some security issue? I am obviously not familiar with the source code in card-openpgp and not an expert in this area, but if someone points me to the right functions I'd need to look at I'd be happy to help adding this. On 20.02.2016 16:41, Douglas E Engert wrote: > Some one who knows the card-openpgp.c code needs to look at this. > > > One more comment. Mathematically, the RSA signature is a large integer. But when used in certificates it is stored as > an ASN.1 BIT STRING with leading 0 (because signature is multiple of 8 bits) followed by the 512 bytes of the signature for the 4096 bit key. > So there is a 1/256 chance the first byte of the actual signature being zero. (I have one such certificate.) > Your card is dropping the leading zero. > > I would have assumed that if all openpgp cards dropped a leading zero byte, that this would have showed up long ago > as a bug in the OpenSC openpgp driver. I could be wrong. But code could be added to the driver to handle this. > It may be OpenPGP does not care, but when used within OpenSC, the leading byte should be there. > > > On 2/19/2016 9:08 AM, Joe...@we... wrote: >> Hi everyone, >> I am using the Gemalto Open GPG dongle v2.1 with a RSA 4096 bit key to generate signatures for relatively short ID-strings. In general the process I set up runs fine, but I get a bad signature for >> about 2% of my inputs. Bad means the data is 1 byte short and fails verification with openssl. But is not just truncated, comparing to a valid signature generated with openssl it looks completely >> different. >> I am doing the following: >> $ echo -ne "CgABEQS/SUEAAAAAAAAINA==" | openssl dgst -binary -sha256 > dgst.txt >> $ tools/pkcs15-crypt.exe -s -k 1 -r 1 -i dgst.txt -o sig.txt --sha-256 --pkcs1 -p 123456 >> $ echo -ne "CgABEQS/SUEAAAAAAAAINA==" | openssl dgst -sha256 -verify pubkey.pem -signature sig.txt >> Verification Failure >> Doing the same with slightly altered input data runs fine: >> $ echo -ne "CgABEQS/SUEAAAAAAAAINB==" | openssl dgst -binary -sha256 > dgst.txt >> $ tools/pkcs15-crypt.exe -s -k 1 -r 1 -i dgst.txt -o sig.txt --sha-256 --pkcs1 -p 123456 >> $ echo -ne "CgABEQS/SUEAAAAAAAAINB==" | openssl dgst -sha256 -verify pubkey.pem -signature sig.txt >> Verified OK >> This is reproducible with different keys (each key fails for different input data though), I saw the same issue when generating rsa signatures with pkcs11-tool (using parameters -s -m RSA-PKCS -i >> dgst.txt -o sig.txt) , again the bad signatures happen for different input data, so to me it seems that certain key/data combinations may have an issue, or I am doing something wrong... >> Please find attached the logs of both runs I mentioned above with OPENSC_DEBUG=9 set (you can see the good run returned 512 bytes as signature, whereas the bad one only returned 511), and the public >> and private key stored on the card I used for this example (which I explicitly generated for this test ;-) ) >> I have no idea what I might be doing wrong, any help would be highly appreciated! >> Thanks >> Jörg >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> >> >> >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> |