Menu
▾
▴
Re: [Opensc-devel] [minidriver] container naming convention
|
From: Vincent Le T. <vin...@my...> - 2015-10-06 17:38:24
|
FYI To test ADCS manual certificate issuance with smart card: Uncheck "Allow private key to be exported" (took me a while to find this) Check "CA certificate manager approval" When doing having a pending request, the certificate request is also saved on the smart card. It can be found later to determine the container. => the container name like "le-SmartcardLogonECC-aa85e03c-faa-07442" seems to live only during the process life and a mapping may be a solution I don't understand the question "If the container name will change, can the minidriver pick the name?" But I meant to say is if the minidriver is changed, the certificate registered on the user certificate store will become invalid because the private key won't be found. Additionally the certificate propagation service may add the certificate twice (one with the old container name, one with the new container name) => ok, I'll see how a mapping can be done between the OpenSC container name and the minidriver one regards, Vincent 2015-10-06 17:25 GMT+02:00 Douglas E Engert <dee...@gm...>: > Other developers, please answer this question about Solution #2. > (We have a lot of old card drivers, that we should consider dropping too.) > > On 10/6/2015 9:50 AM, Vincent Le Toux wrote: > > What I have understood so far about the Windows PKI, is that Windows > create / open / save using a container name stored in memory with the same > process (windows enrollment done immediatly) or when the > > request is defered, get the container name by matching all the public > keys of the card to find the right container. > > If I understand the above, in the deferred mode is the minidriver queried > for all the public keys (or private?) and the minidriver then gets to > set the container name using sc_pkcs15_get_object_guid? > > And in a single process mode, is the > "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process, > and only set when the generate key operation is done? > If so then then you may only need to keep the mapping from > "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver > returns for sc_pkcs15_get_object_guid for the lipe of the session or only > for the last keygen? i.e. you don't need to write it > to the card, because the card would have generated a key and can now > retrieve what it wants to use for the "GUID" using > sc_pkcs15_get_object_guid. > > > > I'm testing it tonight to be 100% sure. > > > > Do you know cards supported in OpenSC that can write a certificate (not > read only) but that can't store the label ? > > Else using the container name as label for rw cards could be the > solution (my #2) > > If there are any incompatible cards : > > 1) they don't work yet so this modification won't impact them > > 2) they can implement there own mapping logic to fix this bug > > > > But: > > 1) the container name will change (and the certificate registration > information too) > > If the container name will change, can the minidriver pick the name? > > > 2) a fallback logic needs to be implemented if some conditions are not > meet. Typically a label too short. > > > > regards, > > Vincent > > > > > > 2015-10-06 16:28 GMT+02:00 Douglas E Engert <dee...@gm... <mailto: > dee...@gm...>>: > > > > > > > > On 10/6/2015 8:20 AM, Vincent Le Toux wrote: > > > Yes, that was my solution #1: > > > after the key generation, retrieve the container name the way it > would be renamed and keep in the current process memory a conversion table. > Each time you would use the first container name, you will > > > be able to find the OpenSC container name. > > > This way, the first containername will be used only as a subsitute > > > > But if you are trying to use an external CA to sign a certificate > request and return the certificate it may be > > a different process at a later time that is writing the > certificate. Could even be the next day if human intervention is needed > > on the CA side to approve the request. > > > > > > > > Solution #2 was to use the containername as a label. This way, the > container name is saved on the card. > > > > Depends on the card. Most PKCS#15 would write the label. Some cards > that emulate PKCS#15 in software > > may generate the label each time. > > > > > > > > I'm not in favour of storing informations on the computer side. > When you are doing a smart card logon with lsass.exe, you do not have much > access (accessing user registry is limited) > > > > > > > I am not either, but for this generate a key, sign a request, send > to CA, retrieve certificate, write certificate to card > > the lsass would not be involved. If you cant write something to the > card, you need to write it somewhere. > > > > Is there anyway to rename (or copy/delete) the container when the > certificate is written? If so the card driver can pick the > > container name, much as it does now for existing certificates. > > > > > vincent > > > > > > 2015-10-06 15:05 GMT+02:00 Douglas E Engert <dee...@gm... > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > dee...@gm...>>>: > > > > > > You ask: Is your message: "we want to have the same "GUID" for > OpenSC for the PIV card than the PIV minidriver" ? > > > > > > NO. I don't see using the OpenSC minidriver for the PIV card, > because Microsoft now supports the PIV. > > > But that is something to consider, as switching drivers on a > system could lead to the driver not finding > > > certificates in the certificate store. > > > They ran into the same problem of coming up with a unique key > container. Their solution of the the last > > > last three bytes, could lead to non unique containers on some > systems as the last three bytes of the FASCN > > > contain much of the uniqness in the FASCN. The OpenSC version > replaces 1 byte in a different location > > > that tended to be the same for all users who might share a > computer. > > > > > > Well here is another idea. > > > > > > When a key is generated, it needs a container so it can then > be associated with the matching certificate > > > when the certificate is written to the card. This operation > usually(?) done by the user or the admin within > > > a few minutes or days at the most. Most cards can not store > arbitrary data. Could the registry (or some file on disk) > > > be used to store some information during this time? Can the > minidriver change the container names in the cert store? This would allow it > > > to rename the container to match what the card driver would > have chosen for it, and delete any temporary registry > > > entries added above. > > > > > > > > > On 10/6/2015 6:55 AM, Vincent Le Toux wrote: > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > regards, > > > > Vincent > > > > > > > > 2015-10-06 1:34 GMT+02:00 Douglas E Engert < > dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... > <mailto:dee...@gm...>> <mailto:dee...@gm... > > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > 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...> <mailto:dee...@gm... > <mailto:dee...@gm...>> <mailto:dee...@gm... > > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > dee...@gm...>>> <mailto:dee...@gm... <mailto: > dee...@gm...> > > > <mailto:dee...@gm... <mailto:dee...@gm...>> > <mailto:dee...@gm... <mailto:dee...@gm...> <mailto: > 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> < > http://www.mysmartlogon.com> <http://www.mysmartlogon.com> < > http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Opensc-devel mailing list > > > > > >Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>> > > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>>> > > > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > -- > > > > > > > > > > Douglas E. Engert <DEE...@gm... > <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto: > DEE...@gm...>> <mailto:DEE...@gm... > > <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto: > DEE...@gm...>>> <mailto:DEE...@gm... <mailto: > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm... > >> > > > <mailto:DEE...@gm... <mailto:DEE...@gm...> > <mailto:DEE...@gm... <mailto:DEE...@gm...>>>>> > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > >Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>> > > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > 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> > <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> < > http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > > Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>> > > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > -- > > > > > > > > Douglas E. Engert <DEE...@gm... <mailto: > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> > <mailto:DEE...@gm... <mailto:DEE...@gm...> > > <mailto:DEE...@gm... <mailto:DEE...@gm...>>>> > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > 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> < > http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > -- > > > > > > Douglas E. Engert <DEE...@gm... <mailto: > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm... > >>> > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... <mailto: > Ope...@li...> <mailto: > 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> < > 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 |
