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
