I looked into the SHA-1specification and into PKCS#11 to see how I could perform the last round of the hash on-device and came up with the following approach: If e.g. the last block of the message digest calculation should be computed on-device and the previous blocks in software, then I would have to transfer the result of my last computation in software as the initial value of the state variables on the card. There seems to be no way to do this with PKCS#11. But then I thought about this and I figured that this optimization will actually be done by the PKCS#11 driver when using mechanism CKM_SHA1_RSA_PKCS, right? Therefore I could use CKM_SHA1_RSA_PKCS directly and the driver would do the trick? Did I understand this correctly?
Regards, Martin 2010/10/19 Martin Boßlet <martin.boss...@googlemail.com> > As mentioned, computing the last round of the hash on the device and > the previous rounds in software would be the perfect thing to have. > Is it ok if I try to implement this for libp11 and submit the solution > for review? If the solution is accepted I could then move on to > integrate this feature into enginePkcs11! > > Best regards, > Martin > > 2010/10/19 Viktor TARASOV <viktor.tara...@opentrust.com>: > > Ludovic Rousseau wrote: > >> 2010/10/19 Martin Paljak <mar...@paljak.pri.ee>: > >> > >>> Hello, > >>> > >>> On Tue, Oct 19, 2010 at 13:38, Martin Boßlet > >>> <martin.boss...@googlemail.com> wrote: > >>> > >>>> I noticed that libp11 (and enginePkcs11, too) only allows to create > >>>> signatures where the hash was computed in software. The PKCS#11 device > >>>> will simply apply the signature algorithm, and the PKCS#1.5 padding is > >>>> created manually. But many devices actually provide support for > >>>> performing the whole procedure on the device (i.e. hashing, signature > >>>> and padding). Some people even consider it a security risk if not the > >>>> entire procedure takes place on the device (tbd). Regardless of that, > >>>> wouldn't it be a nice addition to add support for this in both > >>>> libraries? > >>>> I'd be glad to help out myself, is it possible to contribute? > >>>> > >>> Of course [1] ! > >>> > >>> The reason why hashing is usually done on the host side is speed. > >>> Documents I usually sign are around 100K or even bigger and the smart > >>> card reader interface is not the fastest on earth. > >>> > >> > >> Note: I have not checked the OpenSC or libp11 implementation. > >> A good compromise is to compute the hash value on the host (for speed) > >> except the last round. The last hash round is computed inside the card > >> just before the padding and signature. > >> With that scheme you have both speed and security. > >> > > For some cards, like IAS/ECC, it's the only possible procedure for > PSO_CDS. > > > >> Bye > >> > >> > >>> [1] http://www.opensc-project.org/opensc/wiki/GetInvolved > >>> > >> > >> > > > > > > -- > > Viktor Tarasov <viktor.tara...@opentrust.com> > > > > _______________________________________________ > > opensc-devel mailing list > > opensc-devel@lists.opensc-project.org > > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > >
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
