[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-devel
Subject:    Re: Bad signature when generating key in OpenPGP Java Card Applet
From:       Erik Nellessen <erik.nellessen () informatik ! hu-berlin ! de>
Date:       2016-04-14 13:33:43
Message-ID: 570F9C37.5000602 () informatik ! hu-berlin ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]


The problem really was in jCardSim. I created an issue here:
https://github.com/licel/jcardsim/issues/82

They fixed the bug and I was able to generate the key on the card.

Thank you very much for your help!
Erik

Erik Nellessen:
> You are right, the applet does not compute the signature as described in the \
> specification. 
> Maybe the cause of the problem is, that the environment on my android smartphone \
> behaves differently than on a real Java Card when creating the PKCS1 padding. The \
> question is, if the padding creation in the smartphone environment is not correct \
> according to PKCS1. It could also be, that PKCS1 does not prescribe padding to the \
> full key length and both paddings are correct according to PKCS1. 
> In any case, I will raise the question in jCardSim, which provides the RSA \
> interfaces on the smartphone. 
> For now, thank you very much!
> 
> Erik
> 
> NIIBE Yutaka:
> > On 04/11/2016 10:40 PM, NIIBE Yutaka wrote:
> > > On 04/06/2016 02:14 AM, Erik Nellessen wrote:
> > > > Received APDU (57 bytes): \
> > > > 002A9E9A333031300D060960864801650304020105000420265A93D234241BD20BF0773B6011FD037CBE8B985D487116DC08E6914F38DBD100
> > > > 
> > > 
> > > This is strange.  I think that this is the cause of your problem.
> > > It should be:
> > > 
> > > 002A9E9A20265A93D234241BD20BF0773B6011FD037CBE8B985D487116DC08E6914F38DBD100
> > > 
> > > I mean, scdaemon removes the prefix (which specifies the hash algo)
> > > 
> > > 	3031300D060960864801650304020105000420
> > > 
> > > before sending card.
> > 
> > Sorry, I was wrong.  The APDU is correct (the prefix is removed and
> > added again in the code scd/app-openpgp.c).  I didn't read the code
> > of adding the prefix again, and misunderstood.
> > 
> > 
> > I think that your OpenPGPcard implementation does some mistake for the
> > calculation of length of padding string.
> > 
> > For 2048-bit RSA, the length of octet is 256 (N=256).  I checked
> > OpenPGPcard specification.  It says (in 7.2.8 PSO: COMPUTE DIGITAL
> > SIGNATURE):
> > 
> > The DSI format for RSA:
> > According to PKCS #1 the DSI is generated internally by the card
> > and has the following structure:
> > 
> > Description           Length  Value
> > ----------------------------------------
> > Start byte            1       00
> > Block type            1       01
> > Padding string (PS)   N-3-L   FF...FF
> > Separator             1       00
> > Data field            L       Digestinfo
> > ----------------------------------------
> > 
> > With SHA256 hash, L=19+32=51.  So, the length of PS should be 202
> > (= 256 - 3 - 51).
> > 
> > It seems that it was computed as the length of PS=8 by the applet.
> > 
> > 
> > 
> > _______________________________________________
> > Gnupg-devel mailing list
> > Gnupg-devel@gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> > 
> 
> 
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


["signature.asc" (application/pgp-signature)]

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic