Menu
▾
▴
Re: [Opensc-devel] [minidriver] container naming convention
|
From: Douglas E E. <dee...@gm...> - 2015-10-05 23:42:16
|
https://msdn.microsoft.com/en-us/library/windows/hardware/dn468709(v=vs.85).aspx Says: "For a new container, the Base CSP/KSP selects the next container or a previously vacated one. A container can be vacated by setting the GUID information in the mscp\Map file to zero for that index." Does the minidriver need to pre-populate the table before a key gen? I brought up the PIV, because it is an example of Microsoft not using real GUIDs. and the PIV is read only, intended to be issued by a CMS by a central authority. The OpenSC PIV driver could be loaded, but since Microsoft provides a driver, most people will not use OpenSC for the PIV. On 10/5/2015 4:00 PM, Vincent Le Toux wrote: > Yes I know it is a unique 39 char string. > I reused the term guid because that's what written in the code & in the microsoft specification. > > When you are using the certificate enrollment process, Windows create container (and a key) having a name like: le-SmartcardLogonECC-aa85e03c-faa-07442 > (name+template+guid). It is the responsibility of the requester to set a unique container name (typically using a guid). > But when it wants to save the certificate, it reopens the container and then fails (because this specific name couldn't be found in the cmapfile because it has been replaced with another name) > > The PIV cards are not loaded by the OpenSC minidriver and I thing, could be considered as read only cards. > > => how can I solve the certificate enrollment process for read write cards ? > > Vincent > > > > > 2015-10-05 22:04 GMT+02:00 Douglas E Engert <dee...@gm... <mailto: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> <http://www.mysmartlogon.com/> > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > -- > -- > 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...> |
