Menu
▾
▴
opensc-devel — discussion of developement of OpenSC and related projects
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(26) |
Feb
(64) |
Mar
(78) |
Apr
(36) |
May
(51) |
Jun
(40) |
Jul
(43) |
Aug
(102) |
Sep
(50) |
Oct
(71) |
Nov
(42) |
Dec
(29) |
| 2014 |
Jan
(49) |
Feb
(52) |
Mar
(56) |
Apr
(30) |
May
(31) |
Jun
(52) |
Jul
(76) |
Aug
(19) |
Sep
(82) |
Oct
(95) |
Nov
(58) |
Dec
(76) |
| 2015 |
Jan
(135) |
Feb
(43) |
Mar
(47) |
Apr
(72) |
May
(59) |
Jun
(20) |
Jul
(17) |
Aug
(14) |
Sep
(34) |
Oct
(62) |
Nov
(48) |
Dec
(23) |
| 2016 |
Jan
(18) |
Feb
(55) |
Mar
(24) |
Apr
(20) |
May
(33) |
Jun
(29) |
Jul
(18) |
Aug
(15) |
Sep
(8) |
Oct
(21) |
Nov
(5) |
Dec
(23) |
| 2017 |
Jan
(3) |
Feb
|
Mar
(17) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(20) |
Sep
(17) |
Oct
(21) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(62) |
Feb
(4) |
Mar
(4) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
|
Dec
(5) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(14) |
Feb
(21) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2023 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Vincent Le T. <vin...@my...> - 2015-10-06 14:50:17
|
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. 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) 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...>: > > > 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...>>: > > > > 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...>>>: > > > > > > > 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...>>>>: > > > > > > > > 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/> > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 |
|
From: Douglas E E. <dee...@gm...> - 2015-10-06 14:36:01
|
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...>>: > > 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...>>>: > > > >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...>>>>: > > > > > > 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/> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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...> |
|
From: Vincent Le T. <vin...@my...> - 2015-10-06 13:21:10
|
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 Solution #2 was to use the containername as a label. This way, the container name is saved on the card. 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) vincent 2015-10-06 15:05 GMT+02:00 Douglas E Engert <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...>>: > > > > > 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...>>>: > > > > > > 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/> > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 |
|
From: Douglas E E. <dee...@gm...> - 2015-10-06 13:12:56
|
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...>>: > > 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...>>>: > > > > 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/> > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > 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...> |
|
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 |
|
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...> |
|
From: Vincent Le T. <vin...@my...> - 2015-10-05 21:01:34
|
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...>: > 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...> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
|
From: Douglas E E. <dee...@gm...> - 2015-10-05 20:12:11
|
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...> |
|
From: Vincent Le T. <vin...@my...> - 2015-10-05 19:44:40
|
Run certutil -scinfo and copy/paste the containername into the CSP param (the error is that the container couldn't be found) regards, Vincent 2015-10-05 21:33 GMT+02:00 Bojan Buić <boj...@gm...>: > Thanks Vincent, > > I just replace "Microsoft Base Smart Card Crypto Provider" with "OpenSC > CSP" and now when I call digital signature on my XML throught SignedXml and > RSACryptoServiceProvider (with CSP param : "OpenSC CSP") they ask me PIN > but after I put password got error like : > > The card cannot be accessed because the wrong PIN was presented. > > I am pretty sure that password is correct. > > Why ? > > I use OpenSC 0.15.0 > > Bojan > > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
|
From: Vincent Le T. <vin...@my...> - 2015-10-05 18:53:33
|
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 |
|
From: Vincent Le T. <vin...@my...> - 2015-10-05 17:07:45
|
Just replace "Microsoft Base Smart Card Crypto Provider" by "OpenSC CSP"
and it will work.
Note: the CSP name should not be hardcoded.
You should call SCard* functions to ask for a card and then determine the
CSP name from the card name (see bellow)
The OpenSC CSP is an alias for the Base smart card crypto. It is used to
avoid the ask for a smart card driver each time it is installed. But this
trick doesn't work for ECC smart card logon => I'll have to think about
something else
Here is some c# code to ask for a card and get the CSP name:
private string GetSmartCardProvider()
{
IntPtr hContext = IntPtr.Zero;
// get the xaml windows handle
WindowInteropHelper helper = new WindowInteropHelper(this);
IntPtr reader = IntPtr.Zero;
IntPtr card = IntPtr.Zero;
int error = 0;
try
{
error = NativeMethods.SCardEstablishContext(0, 0,0, ref
hContext);
if (error != 0)
throw new Win32Exception(error, "SCardEstablishContext
0x" + error.ToString("X"));
reader = Marshal.AllocHGlobal(512);
card = Marshal.AllocHGlobal(512);
NativeMethods.OPENCARDNAME_EX dlgStruct = new
NativeMethods.OPENCARDNAME_EX();
// for xaml
dlgStruct.hwndOwner = helper.Handle;
dlgStruct.hSCardContext = hContext;
dlgStruct.dwFlags = 1; //SC_DLG_MINIMAL_UI;
dlgStruct.lpstrRdr = reader;
dlgStruct.nMaxRdr = 256;
dlgStruct.lpstrCard = card;
dlgStruct.nMaxCard = 256;
//dlgStruct.lpstrTitle = "Select Card";
// must be the last
dlgStruct.dwStructSize = Marshal.SizeOf(dlgStruct);
error = NativeMethods.SCardUIDlgSelectCard(ref dlgStruct);
if (error != 0)
throw new Win32Exception(error, "SCardUIDlgSelectCard
0x" + error.ToString("X"));
byte[] bCard = new byte[512];
Marshal.Copy(card, bCard, 0, bCard.Length);
string sCard = new UnicodeEncoding().GetString(bCard);
int providerNameLength = 1024;
StringBuilder providerName = new
StringBuilder(providerNameLength);
int lReturn = NativeMethods.SCardGetCardTypeProviderName(
hContext,
sCard,
2, // SCARD_PROVIDER_CSP
providerName,
ref providerNameLength
);
return providerName.ToString();
}
finally
{
if (hContext != IntPtr.Zero)
NativeMethods.SCardReleaseContext(hContext);
if (card != IntPtr.Zero)
Marshal.FreeHGlobal(card);
if (reader != IntPtr.Zero)
Marshal.FreeHGlobal(reader);
}
}
[DllImport("winscard.dll")]
internal static extern int SCardEstablishContext(UInt32 dwScope,
uint pvReserved1,
uint pvReserved2,
ref IntPtr phContext);
[DllImport("winscard.dll")]
internal static extern int SCardReleaseContext(IntPtr hContext);
[DllImport("Scarddlg.dll", EntryPoint = "SCardUIDlgSelectCardW")]
internal static extern int SCardUIDlgSelectCard(ref
OPENCARDNAME_EX pDlgStruc);
[DllImport("winscard.dll",CharSet=CharSet.Unicode)]
internal static extern int SCardGetCardTypeProviderName(
IntPtr hContext,
string szCardName,
uint dwProviderId,
StringBuilder szProvider,
ref int pcchProvider
);
[StructLayout(LayoutKind.Sequential, CharSet=CharSet.Unicode)]
internal struct OPENCARDNAME_EX
{
public int dwStructSize;
public IntPtr hSCardContext;
public IntPtr hwndOwner;
public int dwFlags;
[MarshalAs(UnmanagedType.LPStr)]
public string lpstrTitle;
[MarshalAs(UnmanagedType.LPStr)]
public string lpstrSearchDesc;
public IntPtr hIcon;
public IntPtr pOpenCardSearchCriteria;
public IntPtr lpfnConnect;
public IntPtr pvUserData;
public int dwShareMode;
public int dwPreferredProtocols;
public IntPtr lpstrRdr;
public int nMaxRdr;
public IntPtr lpstrCard;
public int nMaxCard;
public int dwActiveProtocol;
public IntPtr hCardHandle;
}
regards,
Vincent
2015-10-05 17:18 GMT+02:00 Vincent Le Toux <vin...@my...>
:
> Just replace "Microsoft Base Smart Card Crypto Provider" by "OpenSC CSP"
> and it will work.
>
> Note: the CSP name should not be hardcoded.
> You should call SCard* functions to ask for a card and then determine the
> CSP name from the card name.
>
> The OpenSC CSP is an alias for the Base smart card crypto. It is used to
> avoid the ask for a smart card driver each time it is installed. But this
> trick doesn't work for ECC smart card logon => I'll have to think about
> something else
>
> regards,
> Vincent
>
> 2015-10-05 17:09 GMT+02:00 Bojan Buić <boj...@gm...>:
>
>> Hello,
>>
>> I would like use my HSM device(http://www.smartcard-hsm.com/) through
>> .NET application for storage of X509 certificate.
>> I don't know how setup CSP provider (OpenSC) for this device/USB HSM ?
>> I was try install OpenSC and use RSACryptoServiceProvider with
>> CSPParameters setup to "Microsoft Base Smart Card Crypto Provider" and
>> provider type = 1 but i got error :
>>
>> A smart card was detected but is not the one required for the current
>> operation. The smart card you are using may be missing required driver
>> software or a required certificate. Contact your system administrator
>>
>> Help ?
>>
>> --
>> Bojan Buić
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>
>
> --
> --
> Vincent Le Toux
>
> My Smart Logon
> www.mysmartlogon.com
>
--
--
Vincent Le Toux
My Smart Logon
www.mysmartlogon.com
|
|
From: Bojan B. <boj...@gm...> - 2015-10-05 15:09:26
|
Hello, I would like use my HSM device(http://www.smartcard-hsm.com/) through .NET application for storage of X509 certificate. I don't know how setup CSP provider (OpenSC) for this device/USB HSM ? I was try install OpenSC and use RSACryptoServiceProvider with CSPParameters setup to "Microsoft Base Smart Card Crypto Provider" and provider type = 1 but i got error : A smart card was detected but is not the one required for the current operation. The smart card you are using may be missing required driver software or a required certificate. Contact your system administrator Help ? -- Bojan Buić |
|
From: Douglas E E. <dee...@gm...> - 2015-10-03 21:41:07
|
Going back to this first e-mail: What GitHub wiki page? What commands did you use to initialize the card? If running on a Windows 64 bit machine, did you install both the 64 bit and 32 bit version of OpenSC? Can you use any of the OpenSC tools: pkcs11-tool or pkcs15-tool to see if a key was generated, and a cert loaded? Note for PKCS#11 the ID of the cert, public key (if any) and certificate should be the same. Can you post the certificate to the mailing list? Do you have a Linux system to try running OpenSC? On 9/29/2015 2:58 AM, Matt Campbell wrote: > When I attempt to enroll a user for a smart card login certificate, Windows tells me that the smart card is read-only[1]. I'm running Windows Server 2012 R2 and OpenSC 0.15.0g20150914124137 with a > Smartcard-HSM card and Identiv/SCM Microsystems SCR331 card reader. I've initialized it per the instructions on the GitHub wiki. Any help is appreciated. > > [1] http://i.coreduo.me.uk/U4FuFqe.png > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2015-10-03 21:07:03
|
Possible, but not very likely, as as there usually is some checks for the ASN.1 encoding of at least the length of the cert. For PKCS#15 cards, additional information such as subject maybe extracted from the cert and written to separate files. I suggested trying to read the certificate from the card. I meant using pkcs11-tool, pkcs15-tool or the vendor tool that wrote the certificate. The issue is Windows (and the minidriver) can not find the certificate. Using OpenSC on Linux to read the certificate would also help, as well as a OpenSC debug log. On 10/3/2015 12:01 PM, Kenneth Benson wrote: > One thing I've noticed from other drivers/programs using certs being put > on cards is they almost always want it in the der internal format. If > the cert you put an the card was pem format, it might not be being read > correctly. A possibility? > > Kenneth Benson > -- Douglas E. Engert <DEE...@gm...> |
|
From: Vincent Le T. <vin...@my...> - 2015-10-03 17:40:10
|
yes it is a possibility. What certutil -scinfo / pkcs15-tool -D are returning ? 2015-10-03 19:01 GMT+02:00 Kenneth Benson <pho...@gm...>: > One thing I've noticed from other drivers/programs using certs being put > on cards is they almost always want it in the der internal format. If > the cert you put an the card was pem format, it might not be being read > correctly. A possibility? > > Kenneth Benson > > On 10/3/2015 3:04 AM, Vincent Le Toux wrote: > > @Douglas, are you sure that the certificate request was to be stored as > > a computer account ? > > > > Well copy/paste the output of certutil -scinfo will help a lot. > > The message "couldn't find any valid certificates" means that the > > minidriver couldn't find a certificate associated to a public/key pair. > > That could mean that the certificate wasn't properly saved to the smart > > card (wrong reference / id / label). > > Then if the certificate / subject is wrong, it will fail later with a > > more meaningful error message. > > > > Note: you can check the OpenSSL request by renaming the file to .cer and > > double click on it on Windows or within OpenSSL itself. > > > > Note about computer accounts: > > When a certificate is used by the computer account (opposed to the user > > account), it is stored in the computer certificate store (mmc-> > > certificate-> computer store) > > Inside the certificate properties, you have a reference to the CSP/KSP > > (CertGetCertificateContextProperty[*CERT_KEY_PROV_INFO_PROP_ID*]) => it > > makes the link with the smart card (the gray key icon) > > However most of the applications (like IIS) won't work with smart card > > certificates because they can't issue a dialog to enter the PIN => the > > PIN needs to be set in a configuration file and the application designed > > for that. > > > > regards, > > Vincent > > > > 2015-10-03 0:15 GMT+02:00 Douglas E Engert <dee...@gm... > > <mailto:dee...@gm...>>: > > > > I have only created certificates for users on the card. > > > > So you are trying to place a server certificate on the card? > > Is this server certificate to be used for a Windows service of some > > kind, or > > a something like a web server on linux? > > > > If you have a server with a certificate which is now in software, > > dump the certificate and look at the extensions > > Microsoft uses in its server certificates. > > > > The Microsoft CA has templates for creating certificates that can > > add some of the extensions. > > IIRC, the template can also copy some of the extensions from the > > request. > > > > I don't have an AD CA environment any more, so can not test much. > > > > I would use a special openssl.conf that would be run through "sed" > > that contained: > > > > req_extensions = v3_req@@TYPE@@ # The extensions to add to a > > certificate request > > commonName = @@CN@@ > > > > [ v3_req9A ] > > > > # Extensions to add to a certificate request for login > > > > #basicConstraints = CA:FALSE > > #keyUsage = nonRepudiation, digitalSignature, keyEncipherment > > subjectAltName=otherName:msUPN;UTF8:@@UPN@@ > > > > [ v3_req9D ] > > # Extensions to add to a certificate request for encrypt > > #basicConstraints = CA:FALSE > > keyUsage = critical, keyEncipherment > > subjectAltName=email:@@EMAIL@@ > > > > [ v3_req9C ] > > # Extensions to add to a certificate request for signed email > > #basicConstraints = CA:FALSE > > keyUsage = critical, nonRepudiation, digitalSignature > > subjectAltName=email:@@EMAIL@@ > > > > > > sed was used from a script to replace the @@XX@@ with values to be > > in the new cert. > > @@TYPE@@ would be 9A, 9C or 9D that matched the 3 keys used on a > > PIV card > > and thus selected one of the v3_reqXX to get the extensions and > > values set for type of certificate. > > > > When using certutil each user has their own store. A server > > certificate would be in some system store, > > not sure where. > > > > Do the OpenSC tools show a certificate on the card? > > > > > > On 10/2/2015 3:23 PM, Matt Campbell wrote: > > > Hi Douglas, > > > > > > Could you provide more details on doing this? Admittedly I'm new > to Windows PKI, but when I export the issued certificate from the CA and > write it to the card, Windows tells me that it couldn't find > > > any valid certificates. Could the subject name that I'm using in > OpenSSL to make the request be wrong? > > > > > > openssl req -config openssl.conf -engine pkcs11 -new -key slot_01 > -keyform engine -out req.pem -subj "/CN=<DOMAIN.NAME.FQDN" -text -days 3640 > > > > > > On Tue, Sep 29, 2015 at 7:28 AM, Douglas E Engert > > <dee...@gm... <mailto:dee...@gm...> > > <mailto:dee...@gm... <mailto:dee...@gm...>>> wrote: > > > > > > An alternative way to do this until the minidriver can handle > > writing to a card: > > > (1) generate private key on card > > > (2) Uses openssl and engine_pkcs11 to generate a > > certificate request in PEM format > > > (3) cut-and-paste request into the AD CA web page to > > request certificate. > > > (4) Save certificate from the CA. > > > (5) write the certificate to the card. > > > > > > One of the last tings I did before retiring was to setup a > > proof-of-concept system to issue > > > temporary cards for uses who either are waiting for an > > official PIV card or forgot their card at home. > > > > > > Steps 1, 2 and 5 were done on a virtual Linux system running > > under Windows along with other card management steps. > > > > > > 3 and 4 were done by an AD admin on Windows 7 and transferred. > > > Step 3 also requires an CA template that added the Windows > > smartcard login extension. > > > > > > Check if step 2 could be done by the sc-hsm-tool. > > > > > > > > > On 9/29/2015 3:09 AM, Andreas Schwier wrote: > > > > Dear Matt, > > > > > > > > Windows is right, the minidriver is currently a read-only > > driver. > > > > > > > > The minidriver is currently enhanced with EC support and the > > > > authentication mechanism have changed. See [1] for details. > > > > > > > > I suggest you try an older version of OpenSC or track the > latest > > > > development in the pull request. > > > > > > > > Would be great if you could supply logs while you test. > > > > > > > > Andreas > > > > > > > > [1]https://github.com/OpenSC/OpenSC/pull/566 > > > > > > > > On 09/29/2015 09:58 AM, Matt Campbell wrote: > > > >> When I attempt to enroll a user for a smart card login > > certificate, Windows > > > >> tells me that the smart card is read-only[1]. I'm running > > Windows Server > > > >> 2012 R2 and OpenSC 0.15.0g20150914124137 with a > > Smartcard-HSM card and > > > >> Identiv/SCM Microsystems SCR331 card reader. I've > > initialized it per the > > > >> instructions on the GitHub wiki. Any help is appreciated. > > > >> > > > >> [1]http://i.coreduo.me.uk/U4FuFqe.png > > > >> > > > >> > > > >> > > > >> > > > ------------------------------------------------------------------------------ > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > > > > > -- > > > > 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 > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
|
From: Kenneth B. <pho...@gm...> - 2015-10-03 17:02:04
|
One thing I've noticed from other drivers/programs using certs being put on cards is they almost always want it in the der internal format. If the cert you put an the card was pem format, it might not be being read correctly. A possibility? Kenneth Benson On 10/3/2015 3:04 AM, Vincent Le Toux wrote: > @Douglas, are you sure that the certificate request was to be stored as > a computer account ? > > Well copy/paste the output of certutil -scinfo will help a lot. > The message "couldn't find any valid certificates" means that the > minidriver couldn't find a certificate associated to a public/key pair. > That could mean that the certificate wasn't properly saved to the smart > card (wrong reference / id / label). > Then if the certificate / subject is wrong, it will fail later with a > more meaningful error message. > > Note: you can check the OpenSSL request by renaming the file to .cer and > double click on it on Windows or within OpenSSL itself. > > Note about computer accounts: > When a certificate is used by the computer account (opposed to the user > account), it is stored in the computer certificate store (mmc-> > certificate-> computer store) > Inside the certificate properties, you have a reference to the CSP/KSP > (CertGetCertificateContextProperty[*CERT_KEY_PROV_INFO_PROP_ID*]) => it > makes the link with the smart card (the gray key icon) > However most of the applications (like IIS) won't work with smart card > certificates because they can't issue a dialog to enter the PIN => the > PIN needs to be set in a configuration file and the application designed > for that. > > regards, > Vincent > > 2015-10-03 0:15 GMT+02:00 Douglas E Engert <dee...@gm... > <mailto:dee...@gm...>>: > > I have only created certificates for users on the card. > > So you are trying to place a server certificate on the card? > Is this server certificate to be used for a Windows service of some > kind, or > a something like a web server on linux? > > If you have a server with a certificate which is now in software, > dump the certificate and look at the extensions > Microsoft uses in its server certificates. > > The Microsoft CA has templates for creating certificates that can > add some of the extensions. > IIRC, the template can also copy some of the extensions from the > request. > > I don't have an AD CA environment any more, so can not test much. > > I would use a special openssl.conf that would be run through "sed" > that contained: > > req_extensions = v3_req@@TYPE@@ # The extensions to add to a > certificate request > commonName = @@CN@@ > > [ v3_req9A ] > > # Extensions to add to a certificate request for login > > #basicConstraints = CA:FALSE > #keyUsage = nonRepudiation, digitalSignature, keyEncipherment > subjectAltName=otherName:msUPN;UTF8:@@UPN@@ > > [ v3_req9D ] > # Extensions to add to a certificate request for encrypt > #basicConstraints = CA:FALSE > keyUsage = critical, keyEncipherment > subjectAltName=email:@@EMAIL@@ > > [ v3_req9C ] > # Extensions to add to a certificate request for signed email > #basicConstraints = CA:FALSE > keyUsage = critical, nonRepudiation, digitalSignature > subjectAltName=email:@@EMAIL@@ > > > sed was used from a script to replace the @@XX@@ with values to be > in the new cert. > @@TYPE@@ would be 9A, 9C or 9D that matched the 3 keys used on a > PIV card > and thus selected one of the v3_reqXX to get the extensions and > values set for type of certificate. > > When using certutil each user has their own store. A server > certificate would be in some system store, > not sure where. > > Do the OpenSC tools show a certificate on the card? > > > On 10/2/2015 3:23 PM, Matt Campbell wrote: > > Hi Douglas, > > > > Could you provide more details on doing this? Admittedly I'm new to Windows PKI, but when I export the issued certificate from the CA and write it to the card, Windows tells me that it couldn't find > > any valid certificates. Could the subject name that I'm using in OpenSSL to make the request be wrong? > > > > openssl req -config openssl.conf -engine pkcs11 -new -key slot_01 -keyform engine -out req.pem -subj "/CN=<DOMAIN.NAME.FQDN" -text -days 3640 > > > > On Tue, Sep 29, 2015 at 7:28 AM, Douglas E Engert > <dee...@gm... <mailto:dee...@gm...> > <mailto:dee...@gm... <mailto:dee...@gm...>>> wrote: > > > > An alternative way to do this until the minidriver can handle > writing to a card: > > (1) generate private key on card > > (2) Uses openssl and engine_pkcs11 to generate a > certificate request in PEM format > > (3) cut-and-paste request into the AD CA web page to > request certificate. > > (4) Save certificate from the CA. > > (5) write the certificate to the card. > > > > One of the last tings I did before retiring was to setup a > proof-of-concept system to issue > > temporary cards for uses who either are waiting for an > official PIV card or forgot their card at home. > > > > Steps 1, 2 and 5 were done on a virtual Linux system running > under Windows along with other card management steps. > > > > 3 and 4 were done by an AD admin on Windows 7 and transferred. > > Step 3 also requires an CA template that added the Windows > smartcard login extension. > > > > Check if step 2 could be done by the sc-hsm-tool. > > > > > > On 9/29/2015 3:09 AM, Andreas Schwier wrote: > > > Dear Matt, > > > > > > Windows is right, the minidriver is currently a read-only > driver. > > > > > > The minidriver is currently enhanced with EC support and the > > > authentication mechanism have changed. See [1] for details. > > > > > > I suggest you try an older version of OpenSC or track the latest > > > development in the pull request. > > > > > > Would be great if you could supply logs while you test. > > > > > > Andreas > > > > > > [1]https://github.com/OpenSC/OpenSC/pull/566 > > > > > > On 09/29/2015 09:58 AM, Matt Campbell wrote: > > >> When I attempt to enroll a user for a smart card login > certificate, Windows > > >> tells me that the smart card is read-only[1]. I'm running > Windows Server > > >> 2012 R2 and OpenSC 0.15.0g20150914124137 with a > Smartcard-HSM card and > > >> Identiv/SCM Microsystems SCR331 card reader. I've > initialized it per the > > >> instructions on the GitHub wiki. Any help is appreciated. > > >> > > >> [1]http://i.coreduo.me.uk/U4FuFqe.png > > >> > > >> > > >> > > >> > ------------------------------------------------------------------------------ > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > -- > > 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 > |
|
From: Vincent Le T. <vin...@my...> - 2015-10-03 07:04:27
|
@Douglas, are you sure that the certificate request was to be stored as a computer account ? Well copy/paste the output of certutil -scinfo will help a lot. The message "couldn't find any valid certificates" means that the minidriver couldn't find a certificate associated to a public/key pair. That could mean that the certificate wasn't properly saved to the smart card (wrong reference / id / label). Then if the certificate / subject is wrong, it will fail later with a more meaningful error message. Note: you can check the OpenSSL request by renaming the file to .cer and double click on it on Windows or within OpenSSL itself. Note about computer accounts: When a certificate is used by the computer account (opposed to the user account), it is stored in the computer certificate store (mmc-> certificate-> computer store) Inside the certificate properties, you have a reference to the CSP/KSP (CertGetCertificateContextProperty[*CERT_KEY_PROV_INFO_PROP_ID*]) => it makes the link with the smart card (the gray key icon) However most of the applications (like IIS) won't work with smart card certificates because they can't issue a dialog to enter the PIN => the PIN needs to be set in a configuration file and the application designed for that. regards, Vincent 2015-10-03 0:15 GMT+02:00 Douglas E Engert <dee...@gm...>: > I have only created certificates for users on the card. > > So you are trying to place a server certificate on the card? > Is this server certificate to be used for a Windows service of some kind, > or > a something like a web server on linux? > > If you have a server with a certificate which is now in software, dump the > certificate and look at the extensions > Microsoft uses in its server certificates. > > The Microsoft CA has templates for creating certificates that can add some > of the extensions. > IIRC, the template can also copy some of the extensions from the request. > > I don't have an AD CA environment any more, so can not test much. > > I would use a special openssl.conf that would be run through "sed" that > contained: > > req_extensions = v3_req@@TYPE@@ # The extensions to add to a certificate > request > commonName = @@CN@@ > > [ v3_req9A ] > > # Extensions to add to a certificate request for login > > #basicConstraints = CA:FALSE > #keyUsage = nonRepudiation, digitalSignature, keyEncipherment > subjectAltName=otherName:msUPN;UTF8:@@UPN@@ > > [ v3_req9D ] > # Extensions to add to a certificate request for encrypt > #basicConstraints = CA:FALSE > keyUsage = critical, keyEncipherment > subjectAltName=email:@@EMAIL@@ > > [ v3_req9C ] > # Extensions to add to a certificate request for signed email > #basicConstraints = CA:FALSE > keyUsage = critical, nonRepudiation, digitalSignature > subjectAltName=email:@@EMAIL@@ > > > sed was used from a script to replace the @@XX@@ with values to be in the > new cert. > @@TYPE@@ would be 9A, 9C or 9D that matched the 3 keys used on a PIV > card > and thus selected one of the v3_reqXX to get the extensions and values set > for type of certificate. > > When using certutil each user has their own store. A server certificate > would be in some system store, > not sure where. > > Do the OpenSC tools show a certificate on the card? > > > On 10/2/2015 3:23 PM, Matt Campbell wrote: > > Hi Douglas, > > > > Could you provide more details on doing this? Admittedly I'm new to > Windows PKI, but when I export the issued certificate from the CA and write > it to the card, Windows tells me that it couldn't find > > any valid certificates. Could the subject name that I'm using in OpenSSL > to make the request be wrong? > > > > openssl req -config openssl.conf -engine pkcs11 -new -key slot_01 > -keyform engine -out req.pem -subj "/CN=<DOMAIN.NAME.FQDN" -text -days 3640 > > > > On Tue, Sep 29, 2015 at 7:28 AM, Douglas E Engert <dee...@gm... > <mailto:dee...@gm...>> wrote: > > > > An alternative way to do this until the minidriver can handle > writing to a card: > > (1) generate private key on card > > (2) Uses openssl and engine_pkcs11 to generate a certificate > request in PEM format > > (3) cut-and-paste request into the AD CA web page to request > certificate. > > (4) Save certificate from the CA. > > (5) write the certificate to the card. > > > > One of the last tings I did before retiring was to setup a > proof-of-concept system to issue > > temporary cards for uses who either are waiting for an official PIV > card or forgot their card at home. > > > > Steps 1, 2 and 5 were done on a virtual Linux system running under > Windows along with other card management steps. > > > > 3 and 4 were done by an AD admin on Windows 7 and transferred. > > Step 3 also requires an CA template that added the Windows > smartcard login extension. > > > > Check if step 2 could be done by the sc-hsm-tool. > > > > > > On 9/29/2015 3:09 AM, Andreas Schwier wrote: > > > Dear Matt, > > > > > > Windows is right, the minidriver is currently a read-only driver. > > > > > > The minidriver is currently enhanced with EC support and the > > > authentication mechanism have changed. See [1] for details. > > > > > > I suggest you try an older version of OpenSC or track the latest > > > development in the pull request. > > > > > > Would be great if you could supply logs while you test. > > > > > > Andreas > > > > > > [1]https://github.com/OpenSC/OpenSC/pull/566 > > > > > > On 09/29/2015 09:58 AM, Matt Campbell wrote: > > >> When I attempt to enroll a user for a smart card login > certificate, Windows > > >> tells me that the smart card is read-only[1]. I'm running Windows > Server > > >> 2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM > card and > > >> Identiv/SCM Microsystems SCR331 card reader. I've initialized it > per the > > >> instructions on the GitHub wiki. Any help is appreciated. > > >> > > >> [1]http://i.coreduo.me.uk/U4FuFqe.png > > >> > > >> > > >> > > >> > ------------------------------------------------------------------------------ > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > -- > > 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 |
|
From: Douglas E E. <dee...@gm...> - 2015-10-02 22:22:48
|
I have only created certificates for users on the card. So you are trying to place a server certificate on the card? Is this server certificate to be used for a Windows service of some kind, or a something like a web server on linux? If you have a server with a certificate which is now in software, dump the certificate and look at the extensions Microsoft uses in its server certificates. The Microsoft CA has templates for creating certificates that can add some of the extensions. IIRC, the template can also copy some of the extensions from the request. I don't have an AD CA environment any more, so can not test much. I would use a special openssl.conf that would be run through "sed" that contained: req_extensions = v3_req@@TYPE@@ # The extensions to add to a certificate request commonName = @@CN@@ [ v3_req9A ] # Extensions to add to a certificate request for login #basicConstraints = CA:FALSE #keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName=otherName:msUPN;UTF8:@@UPN@@ [ v3_req9D ] # Extensions to add to a certificate request for encrypt #basicConstraints = CA:FALSE keyUsage = critical, keyEncipherment subjectAltName=email:@@EMAIL@@ [ v3_req9C ] # Extensions to add to a certificate request for signed email #basicConstraints = CA:FALSE keyUsage = critical, nonRepudiation, digitalSignature subjectAltName=email:@@EMAIL@@ sed was used from a script to replace the @@XX@@ with values to be in the new cert. @@TYPE@@ would be 9A, 9C or 9D that matched the 3 keys used on a PIV card and thus selected one of the v3_reqXX to get the extensions and values set for type of certificate. When using certutil each user has their own store. A server certificate would be in some system store, not sure where. Do the OpenSC tools show a certificate on the card? On 10/2/2015 3:23 PM, Matt Campbell wrote: > Hi Douglas, > > Could you provide more details on doing this? Admittedly I'm new to Windows PKI, but when I export the issued certificate from the CA and write it to the card, Windows tells me that it couldn't find > any valid certificates. Could the subject name that I'm using in OpenSSL to make the request be wrong? > > openssl req -config openssl.conf -engine pkcs11 -new -key slot_01 -keyform engine -out req.pem -subj "/CN=<DOMAIN.NAME.FQDN" -text -days 3640 > > On Tue, Sep 29, 2015 at 7:28 AM, Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote: > > An alternative way to do this until the minidriver can handle writing to a card: > (1) generate private key on card > (2) Uses openssl and engine_pkcs11 to generate a certificate request in PEM format > (3) cut-and-paste request into the AD CA web page to request certificate. > (4) Save certificate from the CA. > (5) write the certificate to the card. > > One of the last tings I did before retiring was to setup a proof-of-concept system to issue > temporary cards for uses who either are waiting for an official PIV card or forgot their card at home. > > Steps 1, 2 and 5 were done on a virtual Linux system running under Windows along with other card management steps. > > 3 and 4 were done by an AD admin on Windows 7 and transferred. > Step 3 also requires an CA template that added the Windows smartcard login extension. > > Check if step 2 could be done by the sc-hsm-tool. > > > On 9/29/2015 3:09 AM, Andreas Schwier wrote: > > Dear Matt, > > > > Windows is right, the minidriver is currently a read-only driver. > > > > The minidriver is currently enhanced with EC support and the > > authentication mechanism have changed. See [1] for details. > > > > I suggest you try an older version of OpenSC or track the latest > > development in the pull request. > > > > Would be great if you could supply logs while you test. > > > > Andreas > > > > [1]https://github.com/OpenSC/OpenSC/pull/566 > > > > On 09/29/2015 09:58 AM, Matt Campbell wrote: > >> When I attempt to enroll a user for a smart card login certificate, Windows > >> tells me that the smart card is read-only[1]. I'm running Windows Server > >> 2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM card and > >> Identiv/SCM Microsystems SCR331 card reader. I've initialized it per the > >> instructions on the GitHub wiki. Any help is appreciated. > >> > >> [1]http://i.coreduo.me.uk/U4FuFqe.png > >> > >> > >> > >> ------------------------------------------------------------------------------ > >> > >> > >> > >> _______________________________________________ > >> 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 > > -- Douglas E. Engert <DEE...@gm...> |
|
From: Matt C. <mat...@ou...> - 2015-10-02 20:24:26
|
Hi Douglas, Could you provide more details on doing this? Admittedly I'm new to Windows PKI, but when I export the issued certificate from the CA and write it to the card, Windows tells me that it couldn't find any valid certificates. Could the subject name that I'm using in OpenSSL to make the request be wrong? openssl req -config openssl.conf -engine pkcs11 -new -key slot_01 -keyform engine -out req.pem -subj "/CN=<DOMAIN.NAME.FQDN" -text -days 3640 On Tue, Sep 29, 2015 at 7:28 AM, Douglas E Engert <dee...@gm...> wrote: > An alternative way to do this until the minidriver can handle writing to a > card: > (1) generate private key on card > (2) Uses openssl and engine_pkcs11 to generate a certificate request in > PEM format > (3) cut-and-paste request into the AD CA web page to request certificate. > (4) Save certificate from the CA. > (5) write the certificate to the card. > > One of the last tings I did before retiring was to setup a > proof-of-concept system to issue > temporary cards for uses who either are waiting for an official PIV card > or forgot their card at home. > > Steps 1, 2 and 5 were done on a virtual Linux system running under Windows > along with other card management steps. > > 3 and 4 were done by an AD admin on Windows 7 and transferred. > Step 3 also requires an CA template that added the Windows smartcard > login extension. > > Check if step 2 could be done by the sc-hsm-tool. > > > On 9/29/2015 3:09 AM, Andreas Schwier wrote: > > Dear Matt, > > > > Windows is right, the minidriver is currently a read-only driver. > > > > The minidriver is currently enhanced with EC support and the > > authentication mechanism have changed. See [1] for details. > > > > I suggest you try an older version of OpenSC or track the latest > > development in the pull request. > > > > Would be great if you could supply logs while you test. > > > > Andreas > > > > [1] https://github.com/OpenSC/OpenSC/pull/566 > > > > On 09/29/2015 09:58 AM, Matt Campbell wrote: > >> When I attempt to enroll a user for a smart card login certificate, > Windows > >> tells me that the smart card is read-only[1]. I'm running Windows Server > >> 2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM card and > >> Identiv/SCM Microsystems SCR331 card reader. I've initialized it per the > >> instructions on the GitHub wiki. Any help is appreciated. > >> > >> [1] http://i.coreduo.me.uk/U4FuFqe.png > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> > >> > >> _______________________________________________ > >> 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 > > |
|
From: Matt C. <mat...@ou...> - 2015-10-02 20:18:58
|
Hi Vincent, For some reason the driver wasn't getting installed in my virtual Server 2012 R2 environment, but on my Windows 8.1 machine it seems to work fine. I'm not sure what the problem was. On Tue, Sep 29, 2015 at 10:06 AM, Vincent Le Toux < vin...@my...> wrote: > Hi Matt, > > I'm working on the minidriver. > I confirm that the minidriver has partial write support but only when a > flag is actived. > In addition to the ECC support (see > https://github.com/OpenSC/OpenSC/pull/566), I'm working on that. > > Can you explain to me why you think that the minidriver installation is > not working anymore ? > I've solved the problem related to the minidriver configuration / > installation (requesting the installation of a driver until disabled) but > on my opinion, there is no problem with the installation. > Did you mean the x86 / x64 installer problem ? (32 bits version not > available to 64 bits applications) > > Vincent > > 2015-09-29 16:52 GMT+02:00 Matt Campbell <mat...@ou...>: > >> Hello, Andreas. >> >> I guess I was under the impression that the minidriver had write support >> too. I used a development version of OpenSC because it seems that the >> latest release (0.15) does not install properly on Windows 8.1/Server 2012 >> R2. The installer successfully completes but none of the files are there. >> >> On Tue, Sep 29, 2015 at 3:09 AM, Andreas Schwier < >> and...@ca...> wrote: >> >>> Dear Matt, >>> >>> Windows is right, the minidriver is currently a read-only driver. >>> >>> The minidriver is currently enhanced with EC support and the >>> authentication mechanism have changed. See [1] for details. >>> >>> I suggest you try an older version of OpenSC or track the latest >>> development in the pull request. >>> >>> Would be great if you could supply logs while you test. >>> >>> Andreas >>> >>> [1] https://github.com/OpenSC/OpenSC/pull/566 >>> >>> On 09/29/2015 09:58 AM, Matt Campbell wrote: >>> > When I attempt to enroll a user for a smart card login certificate, >>> Windows >>> > tells me that the smart card is read-only[1]. I'm running Windows >>> Server >>> > 2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM card and >>> > Identiv/SCM Microsystems SCR331 card reader. I've initialized it per >>> the >>> > instructions on the GitHub wiki. Any help is appreciated. >>> > >>> > [1] http://i.coreduo.me.uk/U4FuFqe.png >>> > >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensc-devel mailing list >>> > Ope...@li... >>> > https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> > >>> >>> >>> -- >>> >>> --------- CardContact Software & System Consulting >>> |.##> <##.| Andreas Schwier >>> |# #| Schülerweg 38 >>> |# #| 32429 Minden, Germany >>> |'##> <##'| Phone +49 571 56149 >>> --------- http://www.cardcontact.de >>> http://www.tscons.de >>> http://www.openscdp.org >>> http://www.smartcard-hsm.com >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> >> > > > -- > -- > Vincent Le Toux > > My Smart Logon > www.mysmartlogon.com > |
|
From: Vincent Le T. <vin...@my...> - 2015-09-29 15:40:02
|
Hi Matt, I'm working on the minidriver. I confirm that the minidriver has partial write support but only when a flag is actived. In addition to the ECC support (see https://github.com/OpenSC/OpenSC/pull/566), I'm working on that. Can you explain to me why you think that the minidriver installation is not working anymore ? I've solved the problem related to the minidriver configuration / installation (requesting the installation of a driver until disabled) but on my opinion, there is no problem with the installation. Did you mean the x86 / x64 installer problem ? (32 bits version not available to 64 bits applications) Vincent 2015-09-29 16:52 GMT+02:00 Matt Campbell <mat...@ou...>: > Hello, Andreas. > > I guess I was under the impression that the minidriver had write support > too. I used a development version of OpenSC because it seems that the > latest release (0.15) does not install properly on Windows 8.1/Server 2012 > R2. The installer successfully completes but none of the files are there. > > On Tue, Sep 29, 2015 at 3:09 AM, Andreas Schwier < > and...@ca...> wrote: > >> Dear Matt, >> >> Windows is right, the minidriver is currently a read-only driver. >> >> The minidriver is currently enhanced with EC support and the >> authentication mechanism have changed. See [1] for details. >> >> I suggest you try an older version of OpenSC or track the latest >> development in the pull request. >> >> Would be great if you could supply logs while you test. >> >> Andreas >> >> [1] https://github.com/OpenSC/OpenSC/pull/566 >> >> On 09/29/2015 09:58 AM, Matt Campbell wrote: >> > When I attempt to enroll a user for a smart card login certificate, >> Windows >> > tells me that the smart card is read-only[1]. I'm running Windows Server >> > 2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM card and >> > Identiv/SCM Microsystems SCR331 card reader. I've initialized it per the >> > instructions on the GitHub wiki. Any help is appreciated. >> > >> > [1] http://i.coreduo.me.uk/U4FuFqe.png >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > >> > >> > >> > _______________________________________________ >> > Opensc-devel mailing list >> > Ope...@li... >> > https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > >> >> >> -- >> >> --------- CardContact Software & System Consulting >> |.##> <##.| Andreas Schwier >> |# #| Schülerweg 38 >> |# #| 32429 Minden, Germany >> |'##> <##'| Phone +49 571 56149 >> --------- http://www.cardcontact.de >> http://www.tscons.de >> http://www.openscdp.org >> http://www.smartcard-hsm.com >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
|
From: Matt C. <mat...@ou...> - 2015-09-29 14:52:47
|
Hello, Andreas. I guess I was under the impression that the minidriver had write support too. I used a development version of OpenSC because it seems that the latest release (0.15) does not install properly on Windows 8.1/Server 2012 R2. The installer successfully completes but none of the files are there. On Tue, Sep 29, 2015 at 3:09 AM, Andreas Schwier < and...@ca...> wrote: > Dear Matt, > > Windows is right, the minidriver is currently a read-only driver. > > The minidriver is currently enhanced with EC support and the > authentication mechanism have changed. See [1] for details. > > I suggest you try an older version of OpenSC or track the latest > development in the pull request. > > Would be great if you could supply logs while you test. > > Andreas > > [1] https://github.com/OpenSC/OpenSC/pull/566 > > On 09/29/2015 09:58 AM, Matt Campbell wrote: > > When I attempt to enroll a user for a smart card login certificate, > Windows > > tells me that the smart card is read-only[1]. I'm running Windows Server > > 2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM card and > > Identiv/SCM Microsystems SCR331 card reader. I've initialized it per the > > instructions on the GitHub wiki. Any help is appreciated. > > > > [1] http://i.coreduo.me.uk/U4FuFqe.png > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > -- > > --------- CardContact Software & System Consulting > |.##> <##.| Andreas Schwier > |# #| Schülerweg 38 > |# #| 32429 Minden, Germany > |'##> <##'| Phone +49 571 56149 > --------- http://www.cardcontact.de > http://www.tscons.de > http://www.openscdp.org > http://www.smartcard-hsm.com > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > |
|
From: Douglas E E. <dee...@gm...> - 2015-09-29 12:34:55
|
An alternative way to do this until the minidriver can handle writing to a card: (1) generate private key on card (2) Uses openssl and engine_pkcs11 to generate a certificate request in PEM format (3) cut-and-paste request into the AD CA web page to request certificate. (4) Save certificate from the CA. (5) write the certificate to the card. One of the last tings I did before retiring was to setup a proof-of-concept system to issue temporary cards for uses who either are waiting for an official PIV card or forgot their card at home. Steps 1, 2 and 5 were done on a virtual Linux system running under Windows along with other card management steps. 3 and 4 were done by an AD admin on Windows 7 and transferred. Step 3 also requires an CA template that added the Windows smartcard login extension. Check if step 2 could be done by the sc-hsm-tool. On 9/29/2015 3:09 AM, Andreas Schwier wrote: > Dear Matt, > > Windows is right, the minidriver is currently a read-only driver. > > The minidriver is currently enhanced with EC support and the > authentication mechanism have changed. See [1] for details. > > I suggest you try an older version of OpenSC or track the latest > development in the pull request. > > Would be great if you could supply logs while you test. > > Andreas > > [1] https://github.com/OpenSC/OpenSC/pull/566 > > On 09/29/2015 09:58 AM, Matt Campbell wrote: >> When I attempt to enroll a user for a smart card login certificate, Windows >> tells me that the smart card is read-only[1]. I'm running Windows Server >> 2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM card and >> Identiv/SCM Microsystems SCR331 card reader. I've initialized it per the >> instructions on the GitHub wiki. Any help is appreciated. >> >> [1] http://i.coreduo.me.uk/U4FuFqe.png >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > > -- Douglas E. Engert <DEE...@gm...> |
|
From: helpcrypto h. <hel...@gm...> - 2015-09-29 08:11:52
|
On Mon, Sep 28, 2015 at 6:59 PM, Douglas E Engert <dee...@gm...> wrote: > On 9/28/2015 10:46 AM, helpcrypto helpcrypto wrote: > >> On Mon, Sep 28, 2015 at 3:37 PM, Douglas E Engert <dee...@gm... >> <mailto:dee...@gm...>> wrote: >> >> On 9/28/2015 6:56 AM, helpcrypto helpcrypto wrote: >> >> Hi. >> >> >> As said on first message: PINPADS are out of scope. >> >> We have 2 issues already, both have the same common problem: our >> card is closed and doesn't do things properly. >> >> - The USER pin is sent on cleartext. The middleware should >> stablish a SM so login APDU will be crypted >> >> >> You say pin pad readers out of the question, the PIN has to be >> entered somewhere and sent to the card. >> Yet middleware is going to use the client OS to read it from a >> keyboard, so it is in plaintext somewhere. >> >> >> If the middleware were able to show a dialog to enter the PIN (hence my >> application not providing it), it would be better for me. >> > You may want to look at the Mozilla NSS: > > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Overview > > And if you application is in Java: > > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/JSS > > NSS has software crypto to do the verify and prompt for the PIN. > > A NSS "security device" is actually a PKCS#11 library. > For example with FireFox tools->options->"Security Devices"->Load > is used to register a new PKCS#11 library, which could be OpenSC > to access a smartcard. If your card vendor provides .dll or .so file, > you could use the vendors driver. > > > On Windows you may want to use the Microsoft CryptoAPI. > > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx > > OpenSC provides the minidriver used by the MS CryptoAPI that can be uses > to access smart cards. Most smart card vendors > provide a .dll to use with MS CryptoAPI. > > And for Java with MS CryptoAPI see: > > http://www.oracle.com/technetwork/articles/javase/security-137537.html > Already knew about these alternatives. I think I didn't explained myself properly or you didn't understand. PKCS#11 API has 2 ways of working: requiring the PIN on C_Login or don't ask for it, showing a middleware-GUI. (pinpads apart) As our middleware doesn't show any dialog, we are enforced to send the PIN, so MITM can get the PIN (even keylogger if the PIN dialog is not based on random number locations). In the other hand, If my server want to sign 10 specific documents, theres no way to "detect" the request wasn't altered, because the trust channel between application and card is broken. The only real trustworthy scneario is having a card which securely communicates to server, but we don't have that card. Our is closed and we lack needed keys/privileges. > Also, proxyfying the pkcs#11 library won't do anything, cause the PIN will >> be NULL_PTR and if the middleware establish a SM with the card, the login >> APDU will be cripted. >> >> For me, that would be safe enough. >> > > But not for the user. The PIN is in effect the user password to the card. > If the card was stolen, or used without the user's knowledge all you really > know is the private key on the card signed the document. > On Tue, Sep 29, 2015 at 12:05 AM, Douglas E Engert <dee...@gm...> wrote: > > In your first note, you implied that you were writing an application to > sign documents. > This application might be a web app. You also say you want to send 10 > documents signed by the server > but don't say anything about what is a document. > Have you looked at Adobe Reader? It could be started from a web page, and > it can sign documents, and > use PKCS#11 or Windows Certificate store and thus use a smart card. > > https://helpx.adobe.com/acrobat/kb/certificate-signatures.html > > Or Google for: adobe reader pkcs11 smartcard > > It looks like Adobe Reader can also verify signatures on a document. > Let me be more clear: xml, txt or whatever, not only PDF. I also know what PAdES can do for me, but this is a protocol question, rather than signature-alterbatives. |
|
From: Andreas S. <and...@ca...> - 2015-09-29 08:09:30
|
Dear Matt, Windows is right, the minidriver is currently a read-only driver. The minidriver is currently enhanced with EC support and the authentication mechanism have changed. See [1] for details. I suggest you try an older version of OpenSC or track the latest development in the pull request. Would be great if you could supply logs while you test. Andreas [1] https://github.com/OpenSC/OpenSC/pull/566 On 09/29/2015 09:58 AM, Matt Campbell wrote: > When I attempt to enroll a user for a smart card login certificate, Windows > tells me that the smart card is read-only[1]. I'm running Windows Server > 2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM card and > Identiv/SCM Microsystems SCR331 card reader. I've initialized it per the > instructions on the GitHub wiki. Any help is appreciated. > > [1] http://i.coreduo.me.uk/U4FuFqe.png > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com |
5 messages has been excluded from this view by a project administrator.
