Re: [Opensc-devel] [minidriver] container naming convention

[Douglas E E. <dee...@gm...>]

There were many e-mail around April 2011. The term "GUID" is misleading.
The "GUID" needs to be somewhat unique and based on information stored on the card.
If not already on the card A real guid could be created  but must then be written to the card.
Or some other information unique on the card could be used to generate a "GUID"

As an example, using the NIST demo card 1 with the Microsoft builtin PIV driver on Windows 7
certutil -v -scinfo shows four certificates on the card with these Key Containers:
  581850d6-9d28-ca6d-cc93-25a1685fc105
  581850d6-9d28-ca6d-cc93-25a1685fc10a
  581850d6-9d28-ca6d-cc93-25a1685fc10b
  581850d6-9d28-ca6d-cc93-25a1685fc101

The last 3 bytes are based on the NIST 800-73 table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use"
These are the BER-TLV Tag used to access the certificate objects on every card.

The first 13 bytes are based on the FASC-N which is an agency/user ID. This is the closest thing to a card serial number
and the FASC-N is stored in the CHUID object (A CHUID on the card is required for the Microsoft drivr)
The demo card 1 has a CHUID with
  FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2
Adding spaces:
  D6501858 289D 6DCA CC93 25A1685  9A46927C9D45C86501843E2
Taken these as a DWORD, WORD, 2 bytes, 6 bytes and then revering bytes in the DWORD and WORD:
  581850d6 9d28 ca6d cc93 25a1685

So this is not a real GUID at all, it is a combination of part of the unique ID for the card
and object IDs of certificates objects on the card.

The OpenSC driver card-piv.c is similar, but overlays a different byte from the FASCN  with 01, 02, 03, 04
the IDs used on the OpenSC PIV driver, so the resulting "GUID" is more unique.

The sc_pkcs15_get_object_guid is used to return the "GUID" from the card driver based on
what the card driver can get from the card.

On 10/5/2015 1:53 PM, Vincent Le Toux wrote:
> I'm working on the minidriver read/write mode and especially the certificate enrollment process.
>
> When a container is created on the minidriver, there is 3 ways to create the container:
> 1)
> cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925
> if md_is_guid_as_id = true; the microsoft container name is used as the id
>
> 2)
> cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936
> if
> md_is_guid_as_label = true; the microsoft container name is used as the label
>
> 3) (default)
> cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868
> the card is created with the default label "TODO: key label"
> (the microsoft container name is not used)
>
> The problem is that when the container is loaded:
> 1) if the container name is set on the card
> cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501
> Note: I didn't find in the code a place where the container name is initialized
>
> 2) (default)
> cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517
> a guid is created => the initial container name is not found anymore
>
> => when the container is created in a process, then reloaded, it fails because the container name is different
>
>
> There are many ways to solve this problem:
> A) replace the "TODO key label" with a guid and use a conversion table stored statically.
> This way, the guid for 2) is replaced at the load time
> B) set md_is_guid_as_label as default for the read write card and keep the current way to the read only cards
> ....
>
> Can you give your opinion on this ?
> (the history about that, ...)
>
> regards,
> --
> --
> Vincent Le Toux
>
> My Smart Logon
> www.mysmartlogon.com <http://www.mysmartlogon.com/>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@gm...>