> -----Original Message-----
> From: Viktor Tarasov [mailto:[email protected]]
>
> 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
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
