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

Reply via email to