On 12/7/2011 6:04 AM, Hunter William wrote: >> -----Original Message----- >> From: Viktor Tarasov [mailto:viktor.tara...@gmail.com] >> >> Le 06/12/2011 16:42, Douglas E. Engert a écrit : >>> 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; >> > > I did notice this - however, I also noticed that the piv_get_guid routine > returns values which > are in a different format to the normal routine - it returns e.g. > "1A2B3C....." while the > standard routine returns {1A2B3C......-....-....-.....}. Is this correct? > Surely the serialize > routine should also be called for the card specific routines?
I do not think that this is required. I have not looked at the code for sometime, but I recall that the GUID is a string, and no checks are done to see if is required to be formatted as a GUID. The name having "Guid" in it may have been a bad choice for the variable name. The minidriver actually converts the guid string + null to a wide string. mbstowcs(p->wszGuid, guid, MAX_CONTAINER_NAME_LEN + 1); And the Microsoft CNG cardmod.h has: #define MAX_CONTAINER_NAME_LEN 39 and WCHAR wszGuid [MAX_CONTAINER_NAME_LEN + 1]; 32 hex characters for a GUID + { - - - - } is 38 characters, not 39. The Microsoft certutil when it prints the Microsoft created key container created by the Microsoft PIV driver prints it as: Key Container = c97a8e6b-d21d-b211-b719-00144f5fc105 Note no {} around it, but it does look like a GUID. But from my note: http://www.opensc-project.org/pipermail/opensc-devel/2011-January/015770.html I see how it derived it from data on the card. A Microsoft auto enroll certificate in the keystore as a long Key Container name: Key Container = 544c7d4fa0af9d9dafcd2f27ab3af6e2_b892da20-6957-4560-86fc-63ef6c415dff certutil -verbose -store My can show a lot of stuff. On an original Microsoft smart card there may have been a GUID, but it looks lilke it is really just a string. I think it is just a string, and if a card driver created the string, it should be left as is. > >>> 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.) > > I know that this is recommended within an X.509 certificate, but according to > most of the > specs I have seen, there is no required length or defined value in the > ISO7816-15 structures, > simply a requirement that the ID must be unique per card. This ID could > therefore even be a > single byte (which is used in the example personalisation I have seen). > > However, even if the data is long enough, there is the other problem, that > the serialize_guid > function only uses the first 16-bytes, which may not be enough to include the > unique part of > the object. For example, what if the ID is 17-bytes or larger and just > incremented per object. > >> From Douglas' comments, it seems to me that we need to include code to >> generate this hash > inside the library itself. This would remove the dependency on OpenSSL and > the Windows > CryptoAPI, neither of which are guaranteed. I looked into the FNV hash, and > it is a reasonable > solution, but we require at least a 128-bit hash, which requires a 128 bit > multiplication - so > not so simple. There are other hash options - e.g. MurmurHash3, but actually, > I think our > simplest option is just to build a SHA1 implementation into the library - > there are plenty in > the public domain, and just use SHA1. The only disadvantage of using SHA1 > over something like > FNV or MurmurHash3 is speed, and this is not an issue for the _get_guid > function. > > I can send you a patch to implement this if you agree. Its OK with me, but let others make that decision. > > Regards, > Will > > -- 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