On 12/6/2011 1:04 AM, Hunter William wrote: >> 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. >> > > Ok, this is a good idea. I can make this change. One question though - it > seems that the way things are currently designed place the _get_guid as a > function of a pkcs15 card and not the minidriver. For example, pkcs15-tool > seems to display the guid whether or not the minidriver is in use. >
There are some cards where there is a GUID on the card card driver can provide a routine to get the GUID. in card-piv.c: p15card->ops.get_guid = piv_get_guid; > What this means is that we would need to be able to generate a guid even if > the minidriver is not enabled, The calls to the cryptoAPI can be in the opensc.dll if needed. It does not have to depend on the minidriver. > and that this guid would then be different if you were not on Windows, or > hadn't enabled the minidriver. There are four combination: Windows or not vs OpenSSL or not. A SHA1 hash would be identical if produced by Windows CryptoAPI or by OpenSSL So the code could #ifdef Windows and OpenSSL. The point being that on Windows at least there will always be a GUID and it will be the same if produced by CryptoAPI or by OpenSSL. So the odd situation is NOT windows and NOT OpenSSL. > I guess that currently this is all theoretical, as the guid is only > practically used within the minidriver (as far as I can tell). > Is there a plan to use this elsewhere? Is it acceptable for the guid to be > different if the minidriver is not in use? > I don't know of any plans, as it appears only Windows needs this functionality. Someone else might know more then I do on this. But I could see a help desk using OpenSC on Linux to read a card and get the GUID then go on to a Windows box to see whatr is in the cert store. This the GUID sould be an attribute of the card, and independent of the platform on which it is read/derived. Microsoft has its own PIV card driver, and On 1/20/2011 I sent a note: http://www.opensc-project.org/pipermail/opensc-devel/2011-January/015770.html detailing how Microsoft derived the GUID from the card, based on a official PIV card. This was in the discussion of how to derive the GUID and the key container names. Note that what they did was take FASC-N, sort of an employee/card number and use it as the GUID. (OpenSC takes the FASC-N and use it as a card serial number.) A GUID should be following: RFC 4122 http://www.ietf.org/rfc/rfc4122.txt In that there are the variant bits that tell how this was formed. The code we are discussing and the Microsoft practice of taking the FASC-N and and using it as a GUID does not follow this. But RFC 4122 also says: Interoperability, in any form, with variants other than the one defined here is not guaranteed, and is not likely to be an issue in practice. > I guess the real question is - why is the guid generation a function of the > pkcs15 framework and not the minidriver? Are there future plans for this > 'guid'? If so, and we need it to be the same, then we might need to rather > build in some sort of hash generation functionality into the main code. > So a card driver can provide the GUID if it can. Don't know if there are plans for the GUID. The current OpenSC code without the OpenSSL has was trying to use the serial number and derive a GUID that would be unique. In you situation where the serial number was short, the code appears to not work as expected, as the Microsodt code may be expecting a 16 byte binary number be returned. Using the SHA1 hash is just one way that could solve this problem. As there is still the situation of producing the GUID on a non windows without OpenSSL. There may be other ways to solve this other then using a cryptographic hash, it just has to be somewhat unique to avoid collisions on a single machine using multiple cards. Maybe something like this. It appears to be widely used: http://en.wikipedia.org/wiki/Fowler-Noll-Vo_hash_function http://www.isthe.com/chongo/tech/comp/fnv/index.html > Regards, > Will > _______________________________________________ > 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
