[minidriver] container naming convention

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[minidriver] container naming convention

Vincent Le Toux
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

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Douglas E Engert
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Vincent Le Toux
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 <[hidden email]>:
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel



--
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Douglas E Engert
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 <[hidden email] <mailto:[hidden email]>>:
>
>     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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Vincent Le Toux
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 <[hidden email]>:
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 <[hidden email] <mailto:[hidden email]>>:
>
>     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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel



--
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Douglas E Engert
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 <[hidden email] <mailto:[hidden email]>>:
>
>     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>:
>      >
>      >     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
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >
>      >
>      >     --
>      >
>      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>     >
>     >
>     >     ------------------------------------------------------------------------------
>     >     _______________________________________________
>     >     Opensc-devel mailing list
>      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      > 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Vincent Le Toux
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 <[hidden email]>:
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 <[hidden email] <mailto:[hidden email]>>:
>
>     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>:
>      >
>      >     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
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >
>      >
>      >     --
>      >
>      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>     >
>     >
>     >     ------------------------------------------------------------------------------
>     >     _______________________________________________
>     >     Opensc-devel mailing list
>      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      > 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel



--
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Douglas E Engert


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 <[hidden email] <mailto:[hidden email]>>:
>
>     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>:
>      >      >
>      >      >     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
>      >      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >
>      >      >
>      >      >     --
>      >      >
>      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>>
>     >     >
>     >     >
>     >     >     ------------------------------------------------------------------------------
>     >     >     _______________________________________________
>     >     >     Opensc-devel mailing list
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      > 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
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >
>      >
>      >     --
>      >
>      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >
>      >
>      >     ------------------------------------------------------------------------------
>      >     _______________________________________________
>      >     Opensc-devel mailing list
>      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      > 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Vincent Le Toux
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 <[hidden email]>:


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 <[hidden email] <mailto:[hidden email]>>:
>
>     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>:
>      >      >
>      >      >     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
>      >      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >
>      >      >
>      >      >     --
>      >      >
>      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>>
>     >     >
>     >     >
>     >     >     ------------------------------------------------------------------------------
>     >     >     _______________________________________________
>     >     >     Opensc-devel mailing list
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      > 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
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >
>      >
>      >     --
>      >
>      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >
>      >
>      >     ------------------------------------------------------------------------------
>      >     _______________________________________________
>      >     Opensc-devel mailing list
>      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      > 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel



--
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Douglas E Engert
Other developers, please answer this question about Solution #2.
(We have a lot of old card drivers, that we should consider dropping too.)

On 10/6/2015 9:50 AM, Vincent Le Toux wrote:
> What I have understood so far about the Windows PKI, is that Windows create / open / save using a container name stored in memory with the same process (windows enrollment done immediatly) or when the
> request is defered, get the container name by matching all the public keys of the card to find the right container.

If I understand the above, in the deferred mode is the minidriver queried for all the public keys (or private?) and the minidriver then gets to
set the container name using  sc_pkcs15_get_object_guid?

And in a single process mode, is the "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process,
and only set when the generate key operation is done?
If so then then you may only need to keep the mapping from "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver
returns for sc_pkcs15_get_object_guid for the lipe of the session or only for the last keygen? i.e. you don't need to write it
to the card, because the card would have generated a key and can now retrieve what it wants to use for the "GUID" using sc_pkcs15_get_object_guid.


> I'm testing it tonight to be 100% sure.
>
> Do you know cards supported in OpenSC that can write a certificate (not read only) but that can't store the label ?
> Else using the container name as label for rw cards could be the solution (my #2)
> If there are any incompatible cards :
> 1) they don't work yet so this modification won't impact them
> 2) they can implement there own mapping logic to fix this bug
>
> But:
> 1) the container name will change (and the certificate registration information too)

If the container name will change, can the minidriver pick the name?

> 2) a fallback logic needs to be implemented if some conditions are not meet. Typically a label too short.
>
> regards,
> Vincent
>
>
> 2015-10-06 16:28 GMT+02:00 Douglas E Engert <[hidden email] <mailto:[hidden email]>>:
>
>
>
>     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>:
>     >     >
>     >     >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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]>
>      >     <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>:
>      >      >      >
>      >      >      >     There were many e-mail around April 2011. The term "GUID" is misleading.
>      >      >      >     The "GUID" needs to be somewhat unique and based on information stored on the card.
>      >      >      >     If not already on the card A real guid could be created  but must then be written to the card.
>      >      >      >     Or some other information unique on the card could be used to generate a "GUID"
>      >      >      >
>      >      >      >     As an example, using the NIST demo card 1 with the Microsoft builtin PIV driver on Windows 7
>      >      >      >     certutil -v -scinfo shows four certificates on the card with these Key Containers:
>      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc105
>      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc10a
>      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc10b
>      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc101
>      >      >      >
>      >      >      >     The last 3 bytes are based on the NIST 800-73 table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use"
>      >      >      >     These are the BER-TLV Tag used to access the certificate objects on every card.
>      >      >      >
>      >      >      >     The first 13 bytes are based on the FASC-N which is an agency/user ID. This is the closest thing to a card serial number
>      >      >      >     and the FASC-N is stored in the CHUID object (A CHUID on the card is required for the Microsoft drivr)
>      >      >      >     The demo card 1 has a CHUID with
>      >      >      >        FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2
>      >      >      >     Adding spaces:
>      >      >      >        D6501858 289D 6DCA CC93 25A1685  9A46927C9D45C86501843E2
>      >      >      >     Taken these as a DWORD, WORD, 2 bytes, 6 bytes and then revering bytes in the DWORD and WORD:
>      >      >      >        581850d6 9d28 ca6d cc93 25a1685
>      >      >      >
>      >      >      >     So this is not a real GUID at all, it is a combination of part of the unique ID for the card
>      >      >      >     and object IDs of certificates objects on the card.
>      >      >      >
>      >      >      >     The OpenSC driver card-piv.c is similar, but overlays a different byte from the FASCN  with 01, 02, 03, 04
>      >      >      >     the IDs used on the OpenSC PIV driver, so the resulting "GUID" is more unique.
>      >      >      >
>      >      >      >     The sc_pkcs15_get_object_guid is used to return the "GUID" from the card driver based on
>      >      >      >     what the card driver can get from the card.
>      >      >      >
>      >      >      >     On 10/5/2015 1:53 PM, Vincent Le Toux wrote:
>      >      >      >      > I'm working on the minidriver read/write mode and especially the certificate enrollment process.
>      >      >      >      >
>      >      >      >      > When a container is created on the minidriver, there is 3 ways to create the container:
>      >      >      >      > 1)
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925
>      >      >      >      > if md_is_guid_as_id = true; the microsoft container name is used as the id
>      >      >      >      >
>      >      >      >      > 2)
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936
>      >      >      >      > if
>      >      >      >      > md_is_guid_as_label = true; the microsoft container name is used as the label
>      >      >      >      >
>      >      >      >      > 3) (default)
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868
>      >      >      >      > the card is created with the default label "TODO: key label"
>      >      >      >      > (the microsoft container name is not used)
>      >      >      >      >
>      >      >      >      > The problem is that when the container is loaded:
>      >      >      >      > 1) if the container name is set on the card
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501
>      >      >      >      > Note: I didn't find in the code a place where the container name is initialized
>      >      >      >      >
>      >      >      >      > 2) (default)
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517
>      >      >      >      > a guid is created => the initial container name is not found anymore
>      >      >      >      >
>      >      >      >      > => when the container is created in a process, then reloaded, it fails because the container name is different
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > There are many ways to solve this problem:
>      >      >      >      > A) replace the "TODO key label" with a guid and use a conversion table stored statically.
>      >      >      >      > This way, the guid for 2) is replaced at the load time
>      >      >      >      > B) set md_is_guid_as_label as default for the read write card and keep the current way to the read only cards
>      >      >      >      > ....
>      >      >      >      >
>      >      >      >      > Can you give your opinion on this ?
>      >      >      >      > (the history about that, ...)
>      >      >      >      >
>      >      >      >      > regards,
>      >      >      >      > --
>      >      >      >      > --
>      >      >      >      > Vincent Le Toux
>      >      >      >      >
>      >      >      >      > My Smart Logon
>      >      >      >      > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/>
>     >     >     >      >
>     >     >     >      >
>     >     >     >      > ------------------------------------------------------------------------------
>     >     >     >      >
>     >     >     >      >
>     >     >     >      >
>     >     >     >      > _______________________________________________
>     >     >     >      > Opensc-devel mailing list
>     >      >      >      >[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >      >
>      >      >      >
>      >      >      >     --
>      >      >      >
>      >      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>
>     >     >     >
>     >     >     >
>     >     >     >     ------------------------------------------------------------------------------
>     >     >     >     _______________________________________________
>     >     >     >     Opensc-devel mailing list
>     >      >      >[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      > --
>      >      >      > --
>      >      >      > Vincent Le Toux
>      >      >      >
>      >      >      > My Smart Logon
>      >      >      > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/>
>      >      >      >
>      >      >      >
>      >      >      > ------------------------------------------------------------------------------
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      > _______________________________________________
>      >      >      > Opensc-devel mailing list
>      >      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >
>      >      >
>      >      >     --
>      >      >
>      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >
>      >      >
>      >      >     ------------------------------------------------------------------------------
>      >      >     _______________________________________________
>      >      >     Opensc-devel mailing list
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      > 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
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >
>      >
>      >     --
>      >
>      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >
>      >
>      >     ------------------------------------------------------------------------------
>      >     _______________________________________________
>      >     Opensc-devel mailing list
>      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      > 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Vincent Le Toux
FYI To test ADCS manual certificate issuance with smart card:
Uncheck "Allow private key to be exported" (took me a while to find this)
Check "CA certificate manager approval"

When doing having a pending request, the certificate request is also saved on the smart card.
It can be found later to determine the container.
=> the container name like "le-SmartcardLogonECC-aa85e03c-faa-07442" seems to live only during the process life and a mapping may be a solution

I don't understand the question "If the container name will change, can the minidriver pick the name?"
But I meant to say is if the minidriver is changed, the certificate registered on the user certificate store will become invalid because the private key won't be found.
Additionally the certificate propagation service may add the certificate twice (one with the old container name, one with the new container name)

=> ok, I'll see how a mapping can be done between the OpenSC container name and the minidriver one

regards,
Vincent


2015-10-06 17:25 GMT+02:00 Douglas E Engert <[hidden email]>:
Other developers, please answer this question about Solution #2.
(We have a lot of old card drivers, that we should consider dropping too.)

On 10/6/2015 9:50 AM, Vincent Le Toux wrote:
> What I have understood so far about the Windows PKI, is that Windows create / open / save using a container name stored in memory with the same process (windows enrollment done immediatly) or when the
> request is defered, get the container name by matching all the public keys of the card to find the right container.

If I understand the above, in the deferred mode is the minidriver queried for all the public keys (or private?) and the minidriver then gets to
set the container name using  sc_pkcs15_get_object_guid?

And in a single process mode, is the "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process,
and only set when the generate key operation is done?
If so then then you may only need to keep the mapping from "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver
returns for sc_pkcs15_get_object_guid for the lipe of the session or only for the last keygen? i.e. you don't need to write it
to the card, because the card would have generated a key and can now retrieve what it wants to use for the "GUID" using sc_pkcs15_get_object_guid.


> I'm testing it tonight to be 100% sure.
>
> Do you know cards supported in OpenSC that can write a certificate (not read only) but that can't store the label ?
> Else using the container name as label for rw cards could be the solution (my #2)
> If there are any incompatible cards :
> 1) they don't work yet so this modification won't impact them
> 2) they can implement there own mapping logic to fix this bug
>
> But:
> 1) the container name will change (and the certificate registration information too)

If the container name will change, can the minidriver pick the name?

> 2) a fallback logic needs to be implemented if some conditions are not meet. Typically a label too short.
>
> regards,
> Vincent
>
>
> 2015-10-06 16:28 GMT+02:00 Douglas E Engert <[hidden email] <mailto:[hidden email]>>:
>
>
>
>     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>:
>     >     >
>     >     >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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]>
>      >     <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>:
>      >      >      >
>      >      >      >     There were many e-mail around April 2011. The term "GUID" is misleading.
>      >      >      >     The "GUID" needs to be somewhat unique and based on information stored on the card.
>      >      >      >     If not already on the card A real guid could be created  but must then be written to the card.
>      >      >      >     Or some other information unique on the card could be used to generate a "GUID"
>      >      >      >
>      >      >      >     As an example, using the NIST demo card 1 with the Microsoft builtin PIV driver on Windows 7
>      >      >      >     certutil -v -scinfo shows four certificates on the card with these Key Containers:
>      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc105
>      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc10a
>      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc10b
>      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc101
>      >      >      >
>      >      >      >     The last 3 bytes are based on the NIST 800-73 table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use"
>      >      >      >     These are the BER-TLV Tag used to access the certificate objects on every card.
>      >      >      >
>      >      >      >     The first 13 bytes are based on the FASC-N which is an agency/user ID. This is the closest thing to a card serial number
>      >      >      >     and the FASC-N is stored in the CHUID object (A CHUID on the card is required for the Microsoft drivr)
>      >      >      >     The demo card 1 has a CHUID with
>      >      >      >        FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2
>      >      >      >     Adding spaces:
>      >      >      >        D6501858 289D 6DCA CC93 25A1685  9A46927C9D45C86501843E2
>      >      >      >     Taken these as a DWORD, WORD, 2 bytes, 6 bytes and then revering bytes in the DWORD and WORD:
>      >      >      >        581850d6 9d28 ca6d cc93 25a1685
>      >      >      >
>      >      >      >     So this is not a real GUID at all, it is a combination of part of the unique ID for the card
>      >      >      >     and object IDs of certificates objects on the card.
>      >      >      >
>      >      >      >     The OpenSC driver card-piv.c is similar, but overlays a different byte from the FASCN  with 01, 02, 03, 04
>      >      >      >     the IDs used on the OpenSC PIV driver, so the resulting "GUID" is more unique.
>      >      >      >
>      >      >      >     The sc_pkcs15_get_object_guid is used to return the "GUID" from the card driver based on
>      >      >      >     what the card driver can get from the card.
>      >      >      >
>      >      >      >     On 10/5/2015 1:53 PM, Vincent Le Toux wrote:
>      >      >      >      > I'm working on the minidriver read/write mode and especially the certificate enrollment process.
>      >      >      >      >
>      >      >      >      > When a container is created on the minidriver, there is 3 ways to create the container:
>      >      >      >      > 1)
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925
>      >      >      >      > if md_is_guid_as_id = true; the microsoft container name is used as the id
>      >      >      >      >
>      >      >      >      > 2)
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936
>      >      >      >      > if
>      >      >      >      > md_is_guid_as_label = true; the microsoft container name is used as the label
>      >      >      >      >
>      >      >      >      > 3) (default)
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868
>      >      >      >      > the card is created with the default label "TODO: key label"
>      >      >      >      > (the microsoft container name is not used)
>      >      >      >      >
>      >      >      >      > The problem is that when the container is loaded:
>      >      >      >      > 1) if the container name is set on the card
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501
>      >      >      >      > Note: I didn't find in the code a place where the container name is initialized
>      >      >      >      >
>      >      >      >      > 2) (default)
>      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517
>      >      >      >      > a guid is created => the initial container name is not found anymore
>      >      >      >      >
>      >      >      >      > => when the container is created in a process, then reloaded, it fails because the container name is different
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > There are many ways to solve this problem:
>      >      >      >      > A) replace the "TODO key label" with a guid and use a conversion table stored statically.
>      >      >      >      > This way, the guid for 2) is replaced at the load time
>      >      >      >      > B) set md_is_guid_as_label as default for the read write card and keep the current way to the read only cards
>      >      >      >      > ....
>      >      >      >      >
>      >      >      >      > Can you give your opinion on this ?
>      >      >      >      > (the history about that, ...)
>      >      >      >      >
>      >      >      >      > regards,
>      >      >      >      > --
>      >      >      >      > --
>      >      >      >      > Vincent Le Toux
>      >      >      >      >
>      >      >      >      > My Smart Logon
>      >      >      >      > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/>
>     >     >     >      >
>     >     >     >      >
>     >     >     >      > ------------------------------------------------------------------------------
>     >     >     >      >
>     >     >     >      >
>     >     >     >      >
>     >     >     >      > _______________________________________________
>     >     >     >      > Opensc-devel mailing list
>     >      >      >      >[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >      >
>      >      >      >
>      >      >      >     --
>      >      >      >
>      >      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>
>     >     >     >
>     >     >     >
>     >     >     >     ------------------------------------------------------------------------------
>     >     >     >     _______________________________________________
>     >     >     >     Opensc-devel mailing list
>     >      >      >[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      > --
>      >      >      > --
>      >      >      > Vincent Le Toux
>      >      >      >
>      >      >      > My Smart Logon
>      >      >      > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/>
>      >      >      >
>      >      >      >
>      >      >      > ------------------------------------------------------------------------------
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      > _______________________________________________
>      >      >      > Opensc-devel mailing list
>      >      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >
>      >      >
>      >      >     --
>      >      >
>      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >
>      >      >
>      >      >     ------------------------------------------------------------------------------
>      >      >     _______________________________________________
>      >      >     Opensc-devel mailing list
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      > 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
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >
>      >
>      >     --
>      >
>      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >
>      >
>      >     ------------------------------------------------------------------------------
>      >     _______________________________________________
>      >     Opensc-devel mailing list
>      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      > 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel



--
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Frank Morgner
Disclaimer: I don't use the Minidriver and I know almost nothing about
its internals.

Thanks, Vincent, for trying to make things work. I hope by commenting
the discussion below I did not miss so many of the important details...

From what I read, I think that the mapping you suggested is the most
useful solution. Not only because the mapping needs to be done only
during the lifetime of the process (i.e. you don't need to make it
persistent on the hdd). More importantly I think that the label should
not be saved on the card because it is an arbitrary artifact during the
initialization of the card. It does not have any meaning outside the
machine where the card has been initialized and, as consequence, does
not belong on the card. Also, it is Windows specific and not
standardized by PKCS#15.

What I did not understand so far is the situation when a default label
like "TODO: key label" does make sense. It sounds like as if this
functionality has never been tested in depth.

Greets, Frank.

On Tuesday, October 06 at 07:38PM, Vincent Le Toux wrote:

> FYI To test ADCS manual certificate issuance with smart card:
> Uncheck "Allow private key to be exported" (took me a while to find this)
> Check "CA certificate manager approval"
>
> When doing having a pending request, the certificate request is also saved
> on the smart card.
> It can be found later to determine the container.
> => the container name like "le-SmartcardLogonECC-aa85e03c-faa-07442" seems
> to live only during the process life and a mapping may be a solution
>
> I don't understand the question "If the container name will change, can the
> minidriver pick the name?"
> But I meant to say is if the minidriver is changed, the certificate
> registered on the user certificate store will become invalid because the
> private key won't be found.
> Additionally the certificate propagation service may add the certificate
> twice (one with the old container name, one with the new container name)
>
> => ok, I'll see how a mapping can be done between the OpenSC container name
> and the minidriver one
>
> regards,
> Vincent
>
>
> 2015-10-06 17:25 GMT+02:00 Douglas E Engert <[hidden email]>:
>
> > Other developers, please answer this question about Solution #2.
> > (We have a lot of old card drivers, that we should consider dropping too.)
> >
> > On 10/6/2015 9:50 AM, Vincent Le Toux wrote:
> > > What I have understood so far about the Windows PKI, is that Windows
> > create / open / save using a container name stored in memory with the same
> > process (windows enrollment done immediatly) or when the
> > > request is defered, get the container name by matching all the public
> > keys of the card to find the right container.
> >
> > If I understand the above, in the deferred mode is the minidriver queried
> > for all the public keys (or private?) and the minidriver then gets to
> > set the container name using  sc_pkcs15_get_object_guid?
> >
> > And in a single process mode, is the
> > "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process,
> > and only set when the generate key operation is done?
> > If so then then you may only need to keep the mapping from
> > "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver
> > returns for sc_pkcs15_get_object_guid for the lipe of the session or only
> > for the last keygen? i.e. you don't need to write it
> > to the card, because the card would have generated a key and can now
> > retrieve what it wants to use for the "GUID" using
> > sc_pkcs15_get_object_guid.
> >
> >
> > > I'm testing it tonight to be 100% sure.
> > >
> > > Do you know cards supported in OpenSC that can write a certificate (not
> > read only) but that can't store the label ?
> > > Else using the container name as label for rw cards could be the
> > solution (my #2)
> > > If there are any incompatible cards :
> > > 1) they don't work yet so this modification won't impact them
> > > 2) they can implement there own mapping logic to fix this bug
> > >
> > > But:
> > > 1) the container name will change (and the certificate registration
> > information too)
> >
> > If the container name will change, can the minidriver pick the name?
> >
> > > 2) a fallback logic needs to be implemented if some conditions are not
> > meet. Typically a label too short.
> > >
> > > regards,
> > > Vincent
> > >
> > >
> > > 2015-10-06 16:28 GMT+02:00 Douglas E Engert <[hidden email] <mailto:
> > [hidden email]>>:
> > >
> > >
> > >
> > >     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 <[hidden email]
> > <mailto:[hidden email]> <mailto:[hidden email] <mailto:
> > [hidden email]>>>:
> > >     >
> > >     >     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 <
> > [hidden email] <mailto:[hidden email]> <mailto:[hidden email]
> > <mailto:[hidden email]>> <mailto:[hidden email]
> > >     <mailto:[hidden email]> <mailto:[hidden email] <mailto:
> > [hidden email]>>>>:
> > >     >     >
> > >     >     >
> > 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 <
> > [hidden email] <mailto:[hidden email]> <mailto:[hidden email]
> > <mailto:[hidden email]>> <mailto:[hidden email]
> > >     <mailto:[hidden email]> <mailto:[hidden email] <mailto:
> > [hidden email]>>> <mailto:[hidden email] <mailto:
> > [hidden email]>
> > >      >     <mailto:[hidden email] <mailto:[hidden email]>>
> > <mailto:[hidden email] <mailto:[hidden email]> <mailto:
> > [hidden email] <mailto:[hidden email]>>>>>:
> > >      >      >      >
> > >      >      >      >     There were many e-mail around April 2011. The
> > term "GUID" is misleading.
> > >      >      >      >     The "GUID" needs to be somewhat unique and
> > based on information stored on the card.
> > >      >      >      >     If not already on the card A real guid could be
> > created  but must then be written to the card.
> > >      >      >      >     Or some other information unique on the card
> > could be used to generate a "GUID"
> > >      >      >      >
> > >      >      >      >     As an example, using the NIST demo card 1 with
> > the Microsoft builtin PIV driver on Windows 7
> > >      >      >      >     certutil -v -scinfo shows four certificates on
> > the card with these Key Containers:
> > >      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc105
> > >      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc10a
> > >      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc10b
> > >      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc101
> > >      >      >      >
> > >      >      >      >     The last 3 bytes are based on the NIST 800-73
> > table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use"
> > >      >      >      >     These are the BER-TLV Tag used to access the
> > certificate objects on every card.
> > >      >      >      >
> > >      >      >      >     The first 13 bytes are based on the FASC-N
> > which is an agency/user ID. This is the closest thing to a card serial
> > number
> > >      >      >      >     and the FASC-N is stored in the CHUID object (A
> > CHUID on the card is required for the Microsoft drivr)
> > >      >      >      >     The demo card 1 has a CHUID with
> > >      >      >      >
> > FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2
> > >      >      >      >     Adding spaces:
> > >      >      >      >        D6501858 289D 6DCA CC93 25A1685
> > 9A46927C9D45C86501843E2
> > >      >      >      >     Taken these as a DWORD, WORD, 2 bytes, 6 bytes
> > and then revering bytes in the DWORD and WORD:
> > >      >      >      >        581850d6 9d28 ca6d cc93 25a1685
> > >      >      >      >
> > >      >      >      >     So this is not a real GUID at all, it is a
> > combination of part of the unique ID for the card
> > >      >      >      >     and object IDs of certificates objects on the
> > card.
> > >      >      >      >
> > >      >      >      >     The OpenSC driver card-piv.c is similar, but
> > overlays a different byte from the FASCN  with 01, 02, 03, 04
> > >      >      >      >     the IDs used on the OpenSC PIV driver, so the
> > resulting "GUID" is more unique.
> > >      >      >      >
> > >      >      >      >     The sc_pkcs15_get_object_guid is used to return
> > the "GUID" from the card driver based on
> > >      >      >      >     what the card driver can get from the card.
> > >      >      >      >
> > >      >      >      >     On 10/5/2015 1:53 PM, Vincent Le Toux wrote:
> > >      >      >      >      > I'm working on the minidriver read/write
> > mode and especially the certificate enrollment process.
> > >      >      >      >      >
> > >      >      >      >      > When a container is created on the
> > minidriver, there is 3 ways to create the container:
> > >      >      >      >      > 1)
> > >      >      >      >      > cf
> > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925
> > >      >      >      >      > if md_is_guid_as_id = true; the microsoft
> > container name is used as the id
> > >      >      >      >      >
> > >      >      >      >      > 2)
> > >      >      >      >      > cf
> > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936
> > >      >      >      >      > if
> > >      >      >      >      > md_is_guid_as_label = true; the microsoft
> > container name is used as the label
> > >      >      >      >      >
> > >      >      >      >      > 3) (default)
> > >      >      >      >      > cf
> > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868
> > >      >      >      >      > the card is created with the default label
> > "TODO: key label"
> > >      >      >      >      > (the microsoft container name is not used)
> > >      >      >      >      >
> > >      >      >      >      > The problem is that when the container is
> > loaded:
> > >      >      >      >      > 1) if the container name is set on the card
> > >      >      >      >      > cf
> > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501
> > >      >      >      >      > Note: I didn't find in the code a place
> > where the container name is initialized
> > >      >      >      >      >
> > >      >      >      >      > 2) (default)
> > >      >      >      >      > cf
> > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517
> > >      >      >      >      > a guid is created => the initial container
> > name is not found anymore
> > >      >      >      >      >
> > >      >      >      >      > => when the container is created in a
> > process, then reloaded, it fails because the container name is different
> > >      >      >      >      >
> > >      >      >      >      >
> > >      >      >      >      > There are many ways to solve this problem:
> > >      >      >      >      > A) replace the "TODO key label" with a guid
> > and use a conversion table stored statically.
> > >      >      >      >      > This way, the guid for 2) is replaced at the
> > load time
> > >      >      >      >      > B) set md_is_guid_as_label as default for
> > the read write card and keep the current way to the read only cards
> > >      >      >      >      > ....
> > >      >      >      >      >
> > >      >      >      >      > Can you give your opinion on this ?
> > >      >      >      >      > (the history about that, ...)
> > >      >      >      >      >
> > >      >      >      >      > regards,
> > >      >      >      >      > --
> > >      >      >      >      > --
> > >      >      >      >      > Vincent Le Toux
> > >      >      >      >      >
> > >      >      >      >      > My Smart Logon
> > >      >      >      >      > www.mysmartlogon.com <
> > http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <
> > http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <
> > http://www.mysmartlogon.com/>
> > >     >     >     >      >
> > >     >     >     >      >
> > >     >     >     >      >
> > ------------------------------------------------------------------------------
> > >     >     >     >      >
> > >     >     >     >      >
> > >     >     >     >      >
> > >     >     >     >      > _______________________________________________
> > >     >     >     >      > Opensc-devel mailing list
> > >     >      >      >      >[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>
> > >     <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>>
> > >      >     <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>
> > >     <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>>>
> > >      >      >      >      >
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> > >      >      >      >      >
> > >      >      >      >
> > >      >      >      >     --
> > >      >      >      >
> > >      >      >      >        Douglas E. Engert  <[hidden email]
> > <mailto:[hidden email]> <mailto:[hidden email] <mailto:
> > [hidden email]>> <mailto:[hidden email]
> > >     <mailto:[hidden email]> <mailto:[hidden email] <mailto:
> > [hidden email]>>> <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:[hidden email] <mailto:[hidden email]
> > >>
> > >     >     <mailto:[hidden email] <mailto:[hidden email]>
> > <mailto:[hidden email] <mailto:[hidden email]>>>>>
> > >     >     >     >
> > >     >     >     >
> > >     >     >     >
> >  ------------------------------------------------------------------------------
> > >     >     >     >     _______________________________________________
> > >     >     >     >     Opensc-devel mailing list
> > >     >      >      >[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>
> > >     <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>>
> > >      >     <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>
> > >     <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>>>
> > >      >      >      >
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> > >      >      >      >
> > >      >      >      >
> > >      >      >      >
> > >      >      >      >
> > >      >      >      > --
> > >      >      >      > --
> > >      >      >      > Vincent Le Toux
> > >      >      >      >
> > >      >      >      > My Smart Logon
> > >      >      >      > www.mysmartlogon.com <http://www.mysmartlogon.com>
> > <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <
> > http://www.mysmartlogon.com/>
> > >      >      >      >
> > >      >      >      >
> > >      >      >      >
> > ------------------------------------------------------------------------------
> > >      >      >      >
> > >      >      >      >
> > >      >      >      >
> > >      >      >      > _______________________________________________
> > >      >      >      > Opensc-devel mailing list
> > >      >      >      > [hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>
> > >     <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>>
> > >      >      >      >
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> > >      >      >      >
> > >      >      >
> > >      >      >     --
> > >      >      >
> > >      >      >        Douglas E. Engert  <[hidden email] <mailto:
> > [hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
> > <mailto:[hidden email] <mailto:[hidden email]>
> > >     <mailto:[hidden email] <mailto:[hidden email]>>>>
> > >      >      >
> > >      >      >
> > >      >      >
> >  ------------------------------------------------------------------------------
> > >      >      >     _______________________________________________
> > >      >      >     Opensc-devel mailing list
> > >      >      > [hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>
> > >     <mailto:[hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>>
> > >      >      > 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
> > >      >      > [hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>
> > >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> > >      >      >
> > >      >
> > >      >     --
> > >      >
> > >      >        Douglas E. Engert  <[hidden email] <mailto:
> > [hidden email]> <mailto:[hidden email] <mailto:[hidden email]
> > >>>
> > >      >
> > >      >
> > >      >
> >  ------------------------------------------------------------------------------
> > >      >     _______________________________________________
> > >      >     Opensc-devel mailing list
> > >      > [hidden email] <mailto:
> > [hidden email]> <mailto:
> > [hidden email] <mailto:
> > [hidden email]>>
> > >      > 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
> > >      > [hidden email] <mailto:
> > [hidden email]>
> > >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> > >      >
> > >
> > >     --
> > >
> > >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]
> > >>
> > >
> > >
> > >
> >  ------------------------------------------------------------------------------
> > >     _______________________________________________
> > >     Opensc-devel mailing list
> > >     [hidden email] <mailto:
> > [hidden email]>
> > >     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
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> > >
> >
> > --
> >
> >   Douglas E. Engert  <[hidden email]>
> >
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Opensc-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >
>
>
>
> --
> --
> Vincent Le Toux
>
> My Smart Logon
> www.mysmartlogon.com

> ------------------------------------------------------------------------------

> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel


--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Douglas E Engert
In reply to this post by Vincent Le Toux
What I meant was: Can the the final container name by what is returned by sc_pkcs15_get_object_guid on an existing object.
THis might require the certificate be written to the card before the container name can be determined.
For many cards this is based on the card serial number and something about the key or certificate.


On 10/6/2015 12:38 PM, Vincent Le Toux wrote:
> FYI To test ADCS manual certificate issuance with smart card:
> Uncheck "Allow private key to be exported" (took me a while to find this)
> Check "CA certificate manager approval"
>
> When doing having a pending request, the certificate request is also saved on the smart card.

That will be a problem, as most cards don't know how to store a request. If its just
in the minidriver memory for a process, that should not be a problem.

> It can be found later to determine the container.
> => the container name like "le-SmartcardLogonECC-aa85e03c-faa-07442" seems to live only during the process life and a mapping may be a solution
>
> I don't understand the question "If the container name will change, can the minidriver pick the name?"
> But I meant to say is if the minidriver is changed, the certificate registered on the user certificate store will become invalid because the private key won't be found.
> Additionally the certificate propagation service may add the certificate twice (one with the old container name, one with the new container name)
>
> => ok, I'll see how a mapping can be done between the OpenSC container name and the minidriver one
>
> regards,
> Vincent
>
>
> 2015-10-06 17:25 GMT+02:00 Douglas E Engert <[hidden email] <mailto:[hidden email]>>:
>
>     Other developers, please answer this question about Solution #2.
>     (We have a lot of old card drivers, that we should consider dropping too.)
>
>     On 10/6/2015 9:50 AM, Vincent Le Toux wrote:
>     > What I have understood so far about the Windows PKI, is that Windows create / open / save using a container name stored in memory with the same process (windows enrollment done immediatly) or when the
>     > request is defered, get the container name by matching all the public keys of the card to find the right container.
>
>     If I understand the above, in the deferred mode is the minidriver queried for all the public keys (or private?) and the minidriver then gets to
>     set the container name using  sc_pkcs15_get_object_guid?
>
>     And in a single process mode, is the "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process,
>     and only set when the generate key operation is done?
>     If so then then you may only need to keep the mapping from "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver
>     returns for sc_pkcs15_get_object_guid for the lipe of the session or only for the last keygen? i.e. you don't need to write it
>     to the card, because the card would have generated a key and can now retrieve what it wants to use for the "GUID" using sc_pkcs15_get_object_guid.
>
>
>     > I'm testing it tonight to be 100% sure.
>     >
>     > Do you know cards supported in OpenSC that can write a certificate (not read only) but that can't store the label ?
>     > Else using the container name as label for rw cards could be the solution (my #2)
>     > If there are any incompatible cards :
>     > 1) they don't work yet so this modification won't impact them
>     > 2) they can implement there own mapping logic to fix this bug
>     >
>     > But:
>     > 1) the container name will change (and the certificate registration information too)
>
>     If the container name will change, can the minidriver pick the name?
>
>     > 2) a fallback logic needs to be implemented if some conditions are not meet. Typically a label too short.
>     >
>     > regards,
>     > Vincent
>     >
>     >
>      > 2015-10-06 16:28 GMT+02:00 Douglas E Engert <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >
>     >
>     >     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>:
>     >     >
>     >     >     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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>:
>     >     >     >
>     >     >     >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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]>
>      >     <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>>:
>      >      >      >      >
>      >      >      >      >     There were many e-mail around April 2011. The term "GUID" is misleading.
>      >      >      >      >     The "GUID" needs to be somewhat unique and based on information stored on the card.
>      >      >      >      >     If not already on the card A real guid could be created  but must then be written to the card.
>      >      >      >      >     Or some other information unique on the card could be used to generate a "GUID"
>      >      >      >      >
>      >      >      >      >     As an example, using the NIST demo card 1 with the Microsoft builtin PIV driver on Windows 7
>      >      >      >      >     certutil -v -scinfo shows four certificates on the card with these Key Containers:
>      >      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc105
>      >      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc10a
>      >      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc10b
>      >      >      >      >        581850d6-9d28-ca6d-cc93-25a1685fc101
>      >      >      >      >
>      >      >      >      >     The last 3 bytes are based on the NIST 800-73 table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use"
>      >      >      >      >     These are the BER-TLV Tag used to access the certificate objects on every card.
>      >      >      >      >
>      >      >      >      >     The first 13 bytes are based on the FASC-N which is an agency/user ID. This is the closest thing to a card serial number
>      >      >      >      >     and the FASC-N is stored in the CHUID object (A CHUID on the card is required for the Microsoft drivr)
>      >      >      >      >     The demo card 1 has a CHUID with
>      >      >      >      >        FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2
>      >      >      >      >     Adding spaces:
>      >      >      >      >        D6501858 289D 6DCA CC93 25A1685  9A46927C9D45C86501843E2
>      >      >      >      >     Taken these as a DWORD, WORD, 2 bytes, 6 bytes and then revering bytes in the DWORD and WORD:
>      >      >      >      >        581850d6 9d28 ca6d cc93 25a1685
>      >      >      >      >
>      >      >      >      >     So this is not a real GUID at all, it is a combination of part of the unique ID for the card
>      >      >      >      >     and object IDs of certificates objects on the card.
>      >      >      >      >
>      >      >      >      >     The OpenSC driver card-piv.c is similar, but overlays a different byte from the FASCN  with 01, 02, 03, 04
>      >      >      >      >     the IDs used on the OpenSC PIV driver, so the resulting "GUID" is more unique.
>      >      >      >      >
>      >      >      >      >     The sc_pkcs15_get_object_guid is used to return the "GUID" from the card driver based on
>      >      >      >      >     what the card driver can get from the card.
>      >      >      >      >
>      >      >      >      >     On 10/5/2015 1:53 PM, Vincent Le Toux wrote:
>      >      >      >      >      > I'm working on the minidriver read/write mode and especially the certificate enrollment process.
>      >      >      >      >      >
>      >      >      >      >      > When a container is created on the minidriver, there is 3 ways to create the container:
>      >      >      >      >      > 1)
>      >      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925
>      >      >      >      >      > if md_is_guid_as_id = true; the microsoft container name is used as the id
>      >      >      >      >      >
>      >      >      >      >      > 2)
>      >      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936
>      >      >      >      >      > if
>      >      >      >      >      > md_is_guid_as_label = true; the microsoft container name is used as the label
>      >      >      >      >      >
>      >      >      >      >      > 3) (default)
>      >      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868
>      >      >      >      >      > the card is created with the default label "TODO: key label"
>      >      >      >      >      > (the microsoft container name is not used)
>      >      >      >      >      >
>      >      >      >      >      > The problem is that when the container is loaded:
>      >      >      >      >      > 1) if the container name is set on the card
>      >      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501
>      >      >      >      >      > Note: I didn't find in the code a place where the container name is initialized
>      >      >      >      >      >
>      >      >      >      >      > 2) (default)
>      >      >      >      >      > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517
>      >      >      >      >      > a guid is created => the initial container name is not found anymore
>      >      >      >      >      >
>      >      >      >      >      > => when the container is created in a process, then reloaded, it fails because the container name is different
>      >      >      >      >      >
>      >      >      >      >      >
>      >      >      >      >      > There are many ways to solve this problem:
>      >      >      >      >      > A) replace the "TODO key label" with a guid and use a conversion table stored statically.
>      >      >      >      >      > This way, the guid for 2) is replaced at the load time
>      >      >      >      >      > B) set md_is_guid_as_label as default for the read write card and keep the current way to the read only cards
>      >      >      >      >      > ....
>      >      >      >      >      >
>      >      >      >      >      > Can you give your opinion on this ?
>      >      >      >      >      > (the history about that, ...)
>      >      >      >      >      >
>      >      >      >      >      > regards,
>      >      >      >      >      > --
>      >      >      >      >      > --
>      >      >      >      >      > Vincent Le Toux
>      >      >      >      >      >
>      >      >      >      >      > My Smart Logon
>      >      >      >      >      > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com>
>     <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/>
>     >     >     >     >      >
>     >     >     >     >      >
>     >     >     >     >      > ------------------------------------------------------------------------------
>     >     >     >     >      >
>     >     >     >     >      >
>     >     >     >     >      >
>     >     >     >     >      > _______________________________________________
>     >     >     >     >      > Opensc-devel mailing list
>     >     >      >      >      >[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>     >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>     >      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>     >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>
>     >      >      >      >      >https://lists.sourceforge.net/lists/listinfo/opensc-devel
>     >      >      >      >      >
>     >      >      >      >
>     >      >      >      >     --
>     >      >      >      >
>     >      >      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]>
>      >     <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >     >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>>>>>
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >     ------------------------------------------------------------------------------
>     >     >     >     >     _______________________________________________
>     >     >     >     >     Opensc-devel mailing list
>     >     >      >      >[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>     >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>     >      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>
>      >      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >      >
>      >      >      >      >
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > --
>      >      >      >      > --
>      >      >      >      > Vincent Le Toux
>      >      >      >      >
>      >      >      >      > My Smart Logon
>      >      >      >      > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/>
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > ------------------------------------------------------------------------------
>      >      >      >      >
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > _______________________________________________
>      >      >      >      > Opensc-devel mailing list
>      >      >      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >      >
>      >      >      >
>      >      >      >     --
>      >      >      >
>      >      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>>
>      >      >      >
>      >      >      >
>      >      >      >     ------------------------------------------------------------------------------
>      >      >      >     _______________________________________________
>      >      >      >     Opensc-devel mailing list
>      >      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      > --
>      >      >      > --
>      >      >      > Vincent Le Toux
>      >      >      >
>      >      >      > My Smart Logon
>      >      >      > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/>
>      >      >      >
>      >      >      >
>      >      >      > ------------------------------------------------------------------------------
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      > _______________________________________________
>      >      >      > Opensc-devel mailing list
>      >      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >      >
>      >      >
>      >      >     --
>      >      >
>      >      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>>
>      >      >
>      >      >
>      >      >     ------------------------------------------------------------------------------
>      >      >     _______________________________________________
>      >      >     Opensc-devel mailing list
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >      > 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
>      >      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      >      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >      >
>      >
>      >     --
>      >
>      >        Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>      >
>      >
>      >     ------------------------------------------------------------------------------
>      >     _______________________________________________
>      >     Opensc-devel mailing list
>      > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>      > 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Full-scale, agent-less Infrastructure Monitoring from a single dashboard
Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
Physical-Virtual-Cloud Infrastructure monitoring from one console
Real user monitoring with APM Insights and performance trend reports
Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [minidriver] container naming convention

Vincent Le Toux
Caching the Windows container seems to be more difficult than I thought.

Indeed, when a key is generated, the Windows GUID is saved to the key reference when calling: sc_pkcs15init_generate_key
https://github.com/OpenSC/OpenSC/blob/5dd806815de8ee56c4458a6a00ec7404aa6241b8/src/pkcs15init/pkcs15-lib.c#L1295-L1303

Then this Windows GUID is returned in each further calls to sc_pkcs15_get_object_guid with this key, the function used to return the guid in further minidriver load
https://github.com/OpenSC/OpenSC/blob/5944915e0ef8d8af73c5c41deb9f12c6d35b80c0/src/libopensc/pkcs15.c#L2721-L2728

=> my attempt to do caching on the minidriver source code only is useless

I've also discovered than you can overwrite the container name using a special file stored on the card (function md_pkcs15_update_container_from_do)


I'll need to:
- extend the caching in pkcs15-lib.c / pkcs15.c from a key context to a process context
- add the same code to the save key code (only the key generation does caching)

Vincent

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel