Le 06/12/2011 16:42, Douglas E. Engert a écrit : > 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 I would follow Douglas in his considerations and prefer to remove dependence on '#ifdef OPENSSL' of the default procedure to compose the GUID. The GUID is calculated in the pkcs15 part; so that the particular card driver has the possibility to implement it's own manner to calculate the GUID's value. This possibility is currently used by PIV card. By default the GUID is calculated on the data composed by concatenation of the object's ID and card's serial number. I venture to suppose that the length of this data is sufficiently big to get an appropriate GUID without additional hash procedure. (By default the cryptographic object's ID is itself the SHA1 of public part.) >> Regards, >> Will Kind regards, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
