> -----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? > > 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. Regards, Will _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel