On 12/4/2011 11:00 AM, Viktor Tarasov wrote: > Hello, > > Le 02/12/2011 16:46, Hunter William a écrit : >> I've attached a patch for some updates that I've made to Viktor's >> secure-messaging branch. Sorry about the size and number of changes - I >> didn't initially think that there would be so many. The commit details are >> after this message. I've used the secure-messaging branch because it seems >> to have the most up to date minidriver and IAS/ECC module. (I am working on >> an IAS/ECC card) >> >> I now have both the PKCS#11 module and Minidriver working fairly well for >> Document signing, Email signing and decryption, and client SSL certificate >> verification. And also with PGP, although this is a very clunky interface. >> This is all on a read-only IAS/ECC card. >> >> There may still be some threading/data issues, which Outlook seems to bring >> to the surface quite easily, although the workarounds I have added seem to >> have helped, and Outlook is now just very slow (which is probably normal!). >> >> Let me know if you have any questions about the changes. Most of them should >> be fairly clean. One I forgot to mention in the commit log in the patch is a >> workaround for Windows XP where CardDeleteContext may be called after DETACH >> PROCESS, with bad results (pCardData becomes NULL at some point in the >> middle of CardDeleteContext!). >> >> The one that might need the most thought is the generation of the GUID. The >> way it was >> previously done failed on perfectly valid cards if the ID's were too short. >> Plus, by just >> using a portion of the ID value, the GUID may no longer be unique. However, >> what I do also >> has some issues (SHA1 on the ID's). >> For one, there are issues with changing the GUID on >> existing keys, as they will need to be reloaded into the Microsoft keystore. >> And it is >> probably also not desirable to have the GUID change depending on whether the >> library was >> compiled with openssl or not. But it seems clear that some sort of hash or >> checksum is >> the right way to go. And with the minidriver still in beta, these kind of >> changes should >> be expected by users.
I agree with all of the above. Before the minidriver can move beyond experimental , the issue of a consistent generation of the GUID must be found, Having it depend on OpenSSL's inclusion is not acceptable. > > Thank you, applied in > https://github.com/viktorTarasov/OpenSC/commit/911535b94494abb2c570fbd5097e62ae7d7429e3 > > > Douglas, will you agree with the following from this commit ? Since the minidriver is being built within the Microsoft Crypto framework, rather then using OpenSSL SHA1, we could use a Microsoft hash function. Thus we do not depend on #ifdef ENABLE_OPENSSL for this one purpose. From this example: http://msdn.microsoft.com/en-us/library/windows/desktop/aa382371(v=vs.85).aspx It look like the needed lines (plus some error checking added) could do this: HCRYPTPROV hProv; BYTE *pbBuffer= (BYTE *)"The data that is to be hashed and signed."; DWORD dwBufferLen = strlen((char *)pbBuffer)+1; HCRYPTHASH hHash; CryptAcquireContext( &hProv, NULL, NULL, PROV_RSA_FULL, 0); CryptCreateHash( hProv, CALG_MD5, 0, 0, &hHash); CryptHashData( hHash, pbBuffer, dwBufferLen, 0)); if(hHash) CryptDestroyHash(hHash); if(hProv) CryptReleaseContext(hProv, 0); > > git diff -r HEAD^ src/libopensc/pkcs15.c > diff --git a/src/libopensc/pkcs15.c b/src/libopensc/pkcs15.c > index 76c85d3..fd7326c 100644 > --- a/src/libopensc/pkcs15.c > +++ b/src/libopensc/pkcs15.c > @@ -32,6 +32,10 @@ > #include "pkcs15.h" > #include "asn1.h" > > +#ifdef ENABLE_OPENSSL > +#include<openssl/sha.h> > +#endif > + > static const struct sc_asn1_entry c_asn1_twlabel[] = { > { "twlabel", SC_ASN1_UTF8STRING, SC_ASN1_TAG_UTF8STRING, 0, NULL, > NULL }, > { NULL, 0, 0, 0, NULL, NULL } > @@ -2408,6 +2412,14 @@ sc_pkcs15_get_guid(struct sc_pkcs15_card *p15card, > const struct sc_pkcs15_object > memcpy(guid_bin, id.value, id.len); > memcpy(guid_bin + id.len, serialnr.value, serialnr.len); > > + // If OpenSSL is available (SHA1), then rather use the hash of the > data > + // - this also protects against data being too short > +#ifdef ENABLE_OPENSSL > + SHA1(guid_bin, id.len + serialnr.len, guid_bin); > + id.len = SHA_DIGEST_LENGTH; > + serialnr.len = 0; > +#endif > + > return sc_pkcs15_serialize_guid(guid_bin, id.len + serialnr.len, > flags, out, out_size); > } > > > >> Regards, >> Will > > Kind regards, > Viktor. > > >> ===================== >> >> Minidriver >> ========== >> Workaround some threading and data lifetime issues when card handle changes >> and need to >> re-associate card >> >> Workaround for Windows XP calling DllMain(Detach Process) before >> CardDeleteContext >> >> Better generation of GUID if OpenSSL available >> >> Report PIN tries left/PIN blocked >> >> Corrected PKCS#1 padding handling in CardRSADecrypt >> >> Support SHA256 in CardSignData >> >> PKCS11 module >> ============= >> Allow use of Unwrap keys in C_DecryptInit >> >> CardMod reader module >> ===================== >> Support user specified DLL >> >> Tools >> ===== >> Fix issue where PC/SC system reported card present with zero >> length ATR (when no card actually present) >> >> >> _______________________________________________ >> 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 > > -- 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
