Menu
▾
▴
Re: [Opensc-devel] [minidriver] container naming convention
|
From: Vincent Le T. <vin...@my...> - 2015-10-06 11:55:34
|
No, the Base CSP/KSP populate the cmapfile with the future name of the container before requesting it. When I want to remove one, it remove the container description in the cmapfile (to avoid a reuse) and call CardDeleteContainer. => the minidriver does not need to prepopulate this table because the Base CSP/KSP does it before genkey The term "GUID" is an abuse of language. It means "a unique identifier for container having max 39 chars", but not a GUID as a GUID. Is your message: "we want to have the same "GUID" for OpenSC for the PIV card than the PIV minidriver" ? regards, Vincent 2015-10-06 1:34 GMT+02:00 Douglas E Engert <dee...@gm...>: > > 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...> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
