Menu
▾
▴
opensc-devel — discussion of developement of OpenSC and related projects
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(26) |
Feb
(64) |
Mar
(78) |
Apr
(36) |
May
(51) |
Jun
(40) |
Jul
(43) |
Aug
(102) |
Sep
(50) |
Oct
(71) |
Nov
(42) |
Dec
(29) |
| 2014 |
Jan
(49) |
Feb
(52) |
Mar
(56) |
Apr
(30) |
May
(31) |
Jun
(52) |
Jul
(76) |
Aug
(19) |
Sep
(82) |
Oct
(95) |
Nov
(58) |
Dec
(76) |
| 2015 |
Jan
(135) |
Feb
(43) |
Mar
(47) |
Apr
(72) |
May
(59) |
Jun
(20) |
Jul
(17) |
Aug
(14) |
Sep
(34) |
Oct
(62) |
Nov
(48) |
Dec
(23) |
| 2016 |
Jan
(18) |
Feb
(55) |
Mar
(24) |
Apr
(20) |
May
(33) |
Jun
(29) |
Jul
(18) |
Aug
(15) |
Sep
(8) |
Oct
(21) |
Nov
(5) |
Dec
(23) |
| 2017 |
Jan
(3) |
Feb
|
Mar
(17) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(20) |
Sep
(17) |
Oct
(21) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(62) |
Feb
(4) |
Mar
(4) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
|
Dec
(5) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(14) |
Feb
(21) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2023 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Douglas E E. <dee...@gm...> - 2015-10-19 19:18:31
|
Any interest in writing an OpenSC version of this for Chrome OS? OpenSC supports a "a myriad others". (Sounds like another minidriver or tokend module. -------- Forwarded Message -------- Subject: Re: Issue 220971 in chromium: Req - smartcard support for federal CAC and PIV cards, bank cards Date: Mon, 19 Oct 2015 18:45:25 +0000 From: chr...@go... To: dee...@gm... Comment #122 on issue 220971 by ds...@go...: Req - smartcard support for federal CAC and PIV cards, bank cards https://code.google.com/p/chromium/issues/detail?id=220971 The API to provide system support is already available <https://developer.chrome.com/extensions/certificateProvider> as of Chrome 46. Middleware providers will have to code against this. We have a working version for Gemalto cards. Working on getting PIV and CAC support (and hopefully a myriad others) at the moment. -- You received this message because you starred the issue. You may adjust your notification preferences at: https://code.google.com/hosting/settings Reply to this email to add a comment. |
|
From: Andreas S. <and...@ca...> - 2015-10-19 09:30:45
|
Hi Marek, What does pkcs15-tool -D show ? In the SmartCard-HSM there is a file identifier for the key (0xCC00 + keyid) and an EF with the PKCS#15 description of the key (0xC400 + keyid). For a certificate related to the private key, an EF with 0xCE00 + keyid is allocated. An unrelated certificate (i.e. a CA certificate) is placed in 0xCA00 + index with the meta data in 0xC800 + index. Data objects are placed in either 0xCF00 + index or 0xCD00 + index with meta data in 0xC800 + index. The range 0xCF00 is used for data objects that can be read always, 0xCD00 is used for data protected by the user PIN. The code enumerates file identifier and creates a key object for each key in the range 0xCC01 to 0xCCFF with the meta data from the related EF in the range 0xC401 to 0xC4FF. So if pkcs15-tool still shows the key, then an key object and the meta data are present. You can manually erase the key file and/or meta data file after PIN verification using opensc-tool or a script for the Smart Card Shell. Andreas On 10/13/2015 12:33 PM, Marek Szuba wrote: > Hello, > > A while ago I tried to import several existing X.509 certificates and > its corresponding private key into my SmartCard-HSM, using OpenSC-0.14. > It turned out that I could do that - which surprised me a bit because > later on I read on-line importing shouldn't work for this card - but > only for one certificate at a time, with each subsequent import > overwriting the previous one. I then decided that I'd rather have no > software-generated certificates on the card than have just one and > proceeded to delete the imported data, using pkcs11-tool. The cert and > the pubkey both went without trouble, however whenever I attempt to > delete the private key I get an error: > > $ pkcs11-tool --module /usr/lib/opensc-pkcs11.so -l --delete-object > --type privkey --id 11ac7c18d526f536d80520d4c03b71f4923d4553 > Using slot 1 with a present token (0x1) > Logging in to "SmartCard-HSM (UserPIN)". > Please enter User PIN: > error: PKCS11 function C_DestroyObject() failed: rv = CKR_GENERAL_ERROR > (0x5) > > The same happens now with OpenSC-0.15. > > Is there any way I could get rid of this key from the card without > reinitialising it? > > Yours sincerely, > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com |
|
From: Frank M. <mo...@in...> - 2015-10-16 16:33:12
|
Just for completeness, adding the following PRs allows you to build OpenSC for 10.11 yourself: https://github.com/OpenSC/OpenSC.tokend/pull/18 https://github.com/OpenSC/OpenSC/pull/577 > There are two PR s related pending, one in opensc, one on opensc.tokend > > Am 15. Oktober 2015 13:07:19 MESZ, schrieb Johannes Becker <Joh...@hr...>: > >Hello, > > > >OS X 10.11 complains that OpenSC-0.15.0.dmg is not made for it. > > > >There is a working one on http://wiki.infonotary.com/ > >Is that site trustworthy? > > > >Regards, > > Johannes > > > >--- > > > >http://wiki.infonotary.com/wiki/Installation_of_smart_card_reader_and_smart_card_drivers_in_Mac_OS_X#Download_and_install_OpenSC > > > >------------------------------------------------------------------------------ > >_______________________________________________ > >Opensc-devel mailing list > >Ope...@li... > >https://lists.sourceforge.net/lists/listinfo/opensc-devel > > -- > Frank Morgner -- 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 |
|
From: Frank M. <mo...@in...> - 2015-10-15 11:51:06
|
There are two PR s related pending, one in opensc, one on opensc.tokend Am 15. Oktober 2015 13:07:19 MESZ, schrieb Johannes Becker <Joh...@hr...>: >Hello, > >OS X 10.11 complains that OpenSC-0.15.0.dmg is not made for it. > >There is a working one on http://wiki.infonotary.com/ >Is that site trustworthy? > >Regards, > Johannes > >--- > >http://wiki.infonotary.com/wiki/Installation_of_smart_card_reader_and_smart_card_drivers_in_Mac_OS_X#Download_and_install_OpenSC > >------------------------------------------------------------------------------ >_______________________________________________ >Opensc-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Frank Morgner |
|
From: David W. <dw...@in...> - 2015-10-15 11:38:07
|
On Mon, 2015-10-12 at 20:01 +0300, Martin Paljak wrote: > On 12/10/15 19:30, Jean-Pierre Münch wrote: > > Am 12.10.2015 um 11:27 schrieb Johannes Becker: > > > Hi, > > > > > > our Firefox extension > > > > > > https://chipkarte.hrz.uni-giessen.de/opensc-pkcs11-install.xpi > > > > > > installs opensc-pkcs11.dll as a cryptographic module. It will > > > not work > > > any more with Firefox 43 because it is not signed by Mozilla. > > > > > > Is there a signed extension around? > > Hi, > > > > You theoretically just could submit it for signing yourself (if you > > develop it yourself). > > The wiki entry should explain the how-to: > > https://wiki.mozilla.org/Add-ons/Extension_Signing > > > There's also: > > https://addons.mozilla.org/en-us/firefox/addon/est-pkcs11-load/ > > Source: https://github.com/open-eid/firefox-pkcs11-loader In most cases on Linux and similar platforms, installing any specific PKCs#11 module such as OpenSC is actually the wrong thing to do. Such platforms have a system-wide configuration which indicates which PKCS#11 modules should be loaded into which process. It's handled by p11-kit: http://p11-glue.freedesktop.org/doc/p11-kit/pkcs11-conf.html The above-referenced extensions are basically just working around Mozilla bug #1161219, which is the fact that NSS (and hence Firefox) doesn't *obey* the system configuration. The best way to work around that bug — after you've ensured that bugs are filed in your distribution of choice and that your vote is added to the upstream bug at https://bugzilla.mozilla.org/1161219 — is to load the p11-kit-proxy.so module. That, in turn, will inspect the system configuration and load the appropriate modules. -- David Woodhouse Open Source Technology Centre Dav...@in... Intel Corporation |
|
From: Johannes B. <Joh...@hr...> - 2015-10-15 11:07:53
|
Hello, OS X 10.11 complains that OpenSC-0.15.0.dmg is not made for it. There is a working one on http://wiki.infonotary.com/ Is that site trustworthy? Regards, Johannes --- http://wiki.infonotary.com/wiki/Installation_of_smart_card_reader_and_smart_card_drivers_in_Mac_OS_X#Download_and_install_OpenSC |
|
From: Johannes B. <Joh...@hr...> - 2015-10-15 10:42:05
|
Am 12.10.2015 um 19:01 schrieb Martin Paljak: > > There's also: > > https://addons.mozilla.org/en-us/firefox/addon/est-pkcs11-load/ Great! Thanks a lot! It doesn't work on OS X (10.10). Probably the path should include /Library/OpenSC/lib Our old Firefox extension just provides opensc-pkcs11.so without a path. That works as well. Regards Johannes |
|
From: Marek S. <scr...@wp...> - 2015-10-13 12:26:28
|
Hello again,
Every time I create a key pair on my SmartCard-HSM using Firefox, both
the private and the public key get assigned the generic label "Private
key". When I subsequently import the certificate produced by my CA to
the card, the privkey and the cert (raw pubkey disappears upon import)
get relabelled to just as generic "Certificate". I would like to change
these labels so that it is easier for me to see what is what in the
object dump. According to documentation, one can do this by executing
something along the lines of
pkcs15-init -A <type> -i <ID> -l <label> {-a <pinid>}
However, what I get instead is the error
Failed to change attribute(s): Invalid arguments
This happens for any object type, both with whether without the auth ID
explicitly specified, and regardless of whether or not I specify the PIN
on the command line (incidentally, if I don't I do not get asked for it
before the error appears).
The relevant lines in OpenSC debug log appear to be:
[pkcs15-init] pkcs15-lib.c:3539:sc_pkcs15init_update_file: called
[pkcs15-init] pkcs15-lib.c:3541:sc_pkcs15init_update_file: returning
with: -1300 (Invalid arguments)
[pkcs15-init] pkcs15-lib.c:2753:sc_pkcs15init_update_any_df: Failed to
encode or update xDF: -1300 (Invalid arguments)
Am I doing something wrong or is this feature simply not supported on
this card?
Yours sincerely,
--
MS
|
|
From: Marek S. <scr...@wp...> - 2015-10-13 10:34:02
|
Hello, A while ago I tried to import several existing X.509 certificates and its corresponding private key into my SmartCard-HSM, using OpenSC-0.14. It turned out that I could do that - which surprised me a bit because later on I read on-line importing shouldn't work for this card - but only for one certificate at a time, with each subsequent import overwriting the previous one. I then decided that I'd rather have no software-generated certificates on the card than have just one and proceeded to delete the imported data, using pkcs11-tool. The cert and the pubkey both went without trouble, however whenever I attempt to delete the private key I get an error: $ pkcs11-tool --module /usr/lib/opensc-pkcs11.so -l --delete-object --type privkey --id 11ac7c18d526f536d80520d4c03b71f4923d4553 Using slot 1 with a present token (0x1) Logging in to "SmartCard-HSM (UserPIN)". Please enter User PIN: error: PKCS11 function C_DestroyObject() failed: rv = CKR_GENERAL_ERROR (0x5) The same happens now with OpenSC-0.15. Is there any way I could get rid of this key from the card without reinitialising it? Yours sincerely, -- MS |
|
From: Martin P. <ma...@ma...> - 2015-10-12 17:01:18
|
On 12/10/15 19:30, Jean-Pierre Münch wrote: > Am 12.10.2015 um 11:27 schrieb Johannes Becker: >> Hi, >> >> our Firefox extension >> >> https://chipkarte.hrz.uni-giessen.de/opensc-pkcs11-install.xpi >> >> installs opensc-pkcs11.dll as a cryptographic module. It will not work >> any more with Firefox 43 because it is not signed by Mozilla. >> >> Is there a signed extension around? > Hi, > > You theoretically just could submit it for signing yourself (if you > develop it yourself). > The wiki entry should explain the how-to: > https://wiki.mozilla.org/Add-ons/Extension_Signing There's also: https://addons.mozilla.org/en-us/firefox/addon/est-pkcs11-load/ Source: https://github.com/open-eid/firefox-pkcs11-loader |
|
From: Jean-Pierre M. <ope...@mu...> - 2015-10-12 16:56:55
|
Am 12.10.2015 um 11:27 schrieb Johannes Becker: > Hi, > > our Firefox extension > > https://chipkarte.hrz.uni-giessen.de/opensc-pkcs11-install.xpi > > installs opensc-pkcs11.dll as a cryptographic module. It will not work > any more with Firefox 43 because it is not signed by Mozilla. > > Is there a signed extension around? Hi, You theoretically just could submit it for signing yourself (if you develop it yourself). The wiki entry should explain the how-to: https://wiki.mozilla.org/Add-ons/Extension_Signing BR JPM |
|
From: Johannes B. <Joh...@hr...> - 2015-10-12 09:43:19
|
Hi, our Firefox extension https://chipkarte.hrz.uni-giessen.de/opensc-pkcs11-install.xpi installs opensc-pkcs11.dll as a cryptographic module. It will not work any more with Firefox 43 because it is not signed by Mozilla. Is there a signed extension around? Regards Johannes |
|
From: Vincent Le T. <vin...@my...> - 2015-10-10 10:26:49
|
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 |
|
From: <J.W...@mi...> - 2015-10-09 13:49:46
|
Hi all, Anyone around who succeeded in getting a Kobil mIdentity completely working under linux? (it is a small usb-device, combining flash-memory, SIM-sized card-reader, and RO-mem with windows drivers) If you plug it into a system, you only see the part with the windows drivers. With the tool kobil_midentity_switch, the reader+card become visible, (I just head from Ludovic that it isn't included for Ubuntu, but it is still available for SLES11-SP3 ) Opensc-tool -l show that the card is present, Pkcs11-tool -O -l show some contend and even let me log-in with my PIN. :) However, the main function of the device, is to let you access the flash memory in a secure (PIN) way. How should I achieve that? Under Windows you have all sorts of fancy pop-up displays, asking for PIN and so-on That I don't need. For instance, a comparable product (Ironkey) just has a small CLI-program doing the same for their product. If any pointers, even if it is known to be completely proprietary, and unachievable under Linux, TNX in advance Hans ______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. |
|
From: Nikos M. <n.m...@gm...> - 2015-10-09 09:36:53
|
On Thu, Oct 8, 2015 at 8:49 PM, Frank Morgner <mo...@in...> wrote: > Hi! > Over the last years we have removed engine_pkcs11 and libp11 from the > OpenSC installers for Windows and Mac OS X. Are you planning standalone > binary distribution of libp11/pkcs11_engine for these platforms (see > https://github.com/OpenSC/OpenSC/issues/488)? No. I'll only do source releases. regards, Nikos |
|
From: Frank M. <mo...@in...> - 2015-10-08 18:49:19
|
Hi! Over the last years we have removed engine_pkcs11 and libp11 from the OpenSC installers for Windows and Mac OS X. Are you planning standalone binary distribution of libp11/pkcs11_engine for these platforms (see https://github.com/OpenSC/OpenSC/issues/488)? Greets, Frank. Am Donnerstag, dem 08. Oktober, um 10:31 Uhr schrieb Nikos Mavrogiannopoulos: > Hello, > I've included the majority of the fixes suggested for libp11 and > engine_pkcs11 [0,1] over the years in the repository. I've also > created a basic test suite for both. If there are no objections today, > I'll proceed with a release tomorrow. > > regards, > Nikos > > [0]. https://github.com/OpenSC/engine_pkcs11 > [1]. https://github.com/OpenSC/libp11/ > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > 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 |
|
From: Nikos M. <n.m...@gm...> - 2015-10-08 08:31:16
|
Hello, I've included the majority of the fixes suggested for libp11 and engine_pkcs11 [0,1] over the years in the repository. I've also created a basic test suite for both. If there are no objections today, I'll proceed with a release tomorrow. regards, Nikos [0]. https://github.com/OpenSC/engine_pkcs11 [1]. https://github.com/OpenSC/libp11/ |
|
From: Alexander G. <ago...@gm...> - 2015-10-07 02:09:08
|
On Tue, Oct 6, 2015 at 6:43 PM, Alexander Gostrer <ago...@gm...> wrote: > Hi Doug, > > On Tue, Oct 6, 2015 at 6:00 PM, Douglas E Engert <dee...@gm...> > wrote: > >> I see you sent the same message to the openssl-dev list yesterday, but no >> one has responded yet. >> > > Yes, they do not response too fast :(. Looks like I will need to learn the > TLS protocol and all its options. > >> >> OpenSC has a engine_pkcs11 that can do ECDSA, but no one has added ECDH >> yet. The main reason was that until OpenSSL-1.0.2 the routines in >> ECDSA_METHOD that needed to be replaced were not exposed, and >> it took years for the OpenSSL people to finally do something about this. >> They added ECDSA_METHOD_set_sign and ECDSA_METHOD_set_sign. >> >> I am afraid it might be years until the ECDH has the extra routines need >> to work with an engine. To get the >> ECDSA_METHOD changes into OpenSSL I had to get the engine working using >> the ecdsa/ec_locl.h header file >> to show what was actually needed. >> > > We use the stable branch and we still need to use the ecdsa/ec_locl.h and > other internal header files for the ECDSA. > >> >> >> On 10/6/2015 12:37 PM, Alexander Gostrer wrote: >> > Hi Doug, >> > >> > David suggested to contact you. >> > We are writing an openssl ECDH engine. All private keys are in the >> hardware (including ephemeral keys). I found that the DH_METHOD has both >> (*generate_key) and (*compute_key) methods while the >> > ECDH_METHOD has just the (*compute_key) method. >> >> Your have the ephemeral keys in hardware? Won't that require a different >> ephemeral key for every active connection? >> > > You mean if the server has few open connections then we get into a problem > of luck of the hardware space? We didn't think about it for a reason... > Probably ephemeral keys in hardware will work on the client only. And will > limit it to one active connection only. I see your point. > If the openssl keeps the shared secret with the connection handle then the ephemeral key is not needed once the connection is established. Then each new connection will have a different shared secret even between the same peers. So our approach will not allow to reuse ephemeral keys. I don't know if reusing keys is a strong requirement of TLS - need to read documentation :(. > >> A key is a key, and there is a EC_KEY_generate_key defined in ec.h, that >> will work for ECDSA or ECDH. >> But the ability to generate_key may also need to be exposed if you need >> to have the ephemeral keys created on the card. >> I have not looked at what this would take. >> > > Right but EC_KEY_generate_key() does not have a hook inside: it will > generate a key in the software. There are hooks in EVP_KEY (EVP_PKEY_METHOD > in ec_pmeth.c) but the SSL code calls ECC_KEY stuff only. > >> >> > >> > We would like (once the engine is completed) to use standard >> SSL_accept() etc calls. But the compute_key() returns shared secret based >> on previously generated public/private key pair and the public >> > key is already sent to a peer). Is there a hook to replace the public >> key before it is sent out? Any ideas/plans about adding this hook into the >> code? >> >> Not sure how to answer this. >> > > By any chance do you know who has the best knowledge of SSL/TLS > implementation of openssl and will want to answer few questions? > > >> >> > >> > Thank you, >> > Alex Gostrer. >> > >> > >> > On Tue, Oct 6, 2015 at 7:54 AM, David Woodhouse < >> dw...@in... <mailto:dw...@in...>> wrote: >> > >> > On Tue, 2015-10-06 at 07:52 -0700, Alexander Gostrer wrote: >> > > Yeah, with ECDSA we have no problems. We thought about >> submitting a >> > > patch but the code is pretty complicated and we weren't sure >> that we >> > > completely understand it. Also we wanted to stick with the >> stable >> > > version. >> > >> > You need to fix it in HEAD first. Then we can talk about >> backporting to >> > older versions. >> > >> > > Do you have Doug's email? Don't want to spam other people. >> > >> > Probably best to use the opensc mailing list. >> > ope...@li... <mailto: >> ope...@li...> >> > >> > -- >> > dwmw2 >> > >> > >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > >> > >> > >> > _______________________________________________ >> > Opensc-devel mailing list >> > Ope...@li... >> > https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > >> >> -- >> >> Douglas E. Engert <DEE...@gm...> >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > > |
|
From: Alexander G. <ago...@gm...> - 2015-10-07 01:43:15
|
Hi Doug, On Tue, Oct 6, 2015 at 6:00 PM, Douglas E Engert <dee...@gm...> wrote: > I see you sent the same message to the openssl-dev list yesterday, but no > one has responded yet. > Yes, they do not response too fast :(. Looks like I will need to learn the TLS protocol and all its options. > > OpenSC has a engine_pkcs11 that can do ECDSA, but no one has added ECDH > yet. The main reason was that until OpenSSL-1.0.2 the routines in > ECDSA_METHOD that needed to be replaced were not exposed, and > it took years for the OpenSSL people to finally do something about this. > They added ECDSA_METHOD_set_sign and ECDSA_METHOD_set_sign. > > I am afraid it might be years until the ECDH has the extra routines need > to work with an engine. To get the > ECDSA_METHOD changes into OpenSSL I had to get the engine working using > the ecdsa/ec_locl.h header file > to show what was actually needed. > We use the stable branch and we still need to use the ecdsa/ec_locl.h and other internal header files for the ECDSA. > > > On 10/6/2015 12:37 PM, Alexander Gostrer wrote: > > Hi Doug, > > > > David suggested to contact you. > > We are writing an openssl ECDH engine. All private keys are in the > hardware (including ephemeral keys). I found that the DH_METHOD has both > (*generate_key) and (*compute_key) methods while the > > ECDH_METHOD has just the (*compute_key) method. > > Your have the ephemeral keys in hardware? Won't that require a different > ephemeral key for every active connection? > You mean if the server has few open connections then we get into a problem of luck of the hardware space? We didn't think about it for a reason... Probably ephemeral keys in hardware will work on the client only. And will limit it to one active connection only. I see your point. > > A key is a key, and there is a EC_KEY_generate_key defined in ec.h, that > will work for ECDSA or ECDH. > But the ability to generate_key may also need to be exposed if you need to > have the ephemeral keys created on the card. > I have not looked at what this would take. > Right but EC_KEY_generate_key() does not have a hook inside: it will generate a key in the software. There are hooks in EVP_KEY (EVP_PKEY_METHOD in ec_pmeth.c) but the SSL code calls ECC_KEY stuff only. > > > > > We would like (once the engine is completed) to use standard > SSL_accept() etc calls. But the compute_key() returns shared secret based > on previously generated public/private key pair and the public > > key is already sent to a peer). Is there a hook to replace the public > key before it is sent out? Any ideas/plans about adding this hook into the > code? > > Not sure how to answer this. > By any chance do you know who has the best knowledge of SSL/TLS implementation of openssl and will want to answer few questions? > > > > > Thank you, > > Alex Gostrer. > > > > > > On Tue, Oct 6, 2015 at 7:54 AM, David Woodhouse <dw...@in... > <mailto:dw...@in...>> wrote: > > > > On Tue, 2015-10-06 at 07:52 -0700, Alexander Gostrer wrote: > > > Yeah, with ECDSA we have no problems. We thought about > submitting a > > > patch but the code is pretty complicated and we weren't sure > that we > > > completely understand it. Also we wanted to stick with the > stable > > > version. > > > > You need to fix it in HEAD first. Then we can talk about > backporting to > > older versions. > > > > > Do you have Doug's email? Don't want to spam other people. > > > > Probably best to use the opensc mailing list. > > ope...@li... <mailto: > ope...@li...> > > > > -- > > dwmw2 > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm...> > > > > ------------------------------------------------------------------------------ > 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: Douglas E E. <dee...@gm...> - 2015-10-07 01:18:45
|
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 <dee...@gm... <mailto:dee...@gm...>>: > > Other developers, please answer this question about Solution #2. > (We have a lot of old card drivers, that we should consider dropping too.) > > On 10/6/2015 9:50 AM, Vincent Le Toux wrote: > > What I have understood so far about the Windows PKI, is that Windows create / open / save using a container name stored in memory with the same process (windows enrollment done immediatly) or when the > > request is defered, get the container name by matching all the public keys of the card to find the right container. > > If I understand the above, in the deferred mode is the minidriver queried for all the public keys (or private?) and the minidriver then gets to > set the container name using sc_pkcs15_get_object_guid? > > And in a single process mode, is the "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process, > and only set when the generate key operation is done? > If so then then you may only need to keep the mapping from "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver > returns for sc_pkcs15_get_object_guid for the lipe of the session or only for the last keygen? i.e. you don't need to write it > to the card, because the card would have generated a key and can now retrieve what it wants to use for the "GUID" using sc_pkcs15_get_object_guid. > > > > I'm testing it tonight to be 100% sure. > > > > Do you know cards supported in OpenSC that can write a certificate (not read only) but that can't store the label ? > > Else using the container name as label for rw cards could be the solution (my #2) > > If there are any incompatible cards : > > 1) they don't work yet so this modification won't impact them > > 2) they can implement there own mapping logic to fix this bug > > > > But: > > 1) the container name will change (and the certificate registration information too) > > If the container name will change, can the minidriver pick the name? > > > 2) a fallback logic needs to be implemented if some conditions are not meet. Typically a label too short. > > > > regards, > > Vincent > > > > > > 2015-10-06 16:28 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>>: > > > > > > > > On 10/6/2015 8:20 AM, Vincent Le Toux wrote: > > > Yes, that was my solution #1: > > > after the key generation, retrieve the container name the way it would be renamed and keep in the current process memory a conversion table. Each time you would use the first container name, you will > > > be able to find the OpenSC container name. > > > This way, the first containername will be used only as a subsitute > > > > But if you are trying to use an external CA to sign a certificate request and return the certificate it may be > > a different process at a later time that is writing the certificate. Could even be the next day if human intervention is needed > > on the CA side to approve the request. > > > > > > > > Solution #2 was to use the containername as a label. This way, the container name is saved on the card. > > > > Depends on the card. Most PKCS#15 would write the label. Some cards that emulate PKCS#15 in software > > may generate the label each time. > > > > > > > > I'm not in favour of storing informations on the computer side. When you are doing a smart card logon with lsass.exe, you do not have much access (accessing user registry is limited) > > > > > > > I am not either, but for this generate a key, sign a request, send to CA, retrieve certificate, write certificate to card > > the lsass would not be involved. If you cant write something to the card, you need to write it somewhere. > > > > Is there anyway to rename (or copy/delete) the container when the certificate is written? If so the card driver can pick the > > container name, much as it does now for existing certificates. > > > > > vincent > > > > > > 2015-10-06 15:05 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>>>: > > > > > > You ask: Is your message: "we want to have the same "GUID" for OpenSC for the PIV card than the PIV minidriver" ? > > > > > > NO. I don't see using the OpenSC minidriver for the PIV card, because Microsoft now supports the PIV. > > > But that is something to consider, as switching drivers on a system could lead to the driver not finding > > > certificates in the certificate store. > > > They ran into the same problem of coming up with a unique key container. Their solution of the the last > > > last three bytes, could lead to non unique containers on some systems as the last three bytes of the FASCN > > > contain much of the uniqness in the FASCN. The OpenSC version replaces 1 byte in a different location > > > that tended to be the same for all users who might share a computer. > > > > > > Well here is another idea. > > > > > > When a key is generated, it needs a container so it can then be associated with the matching certificate > > > when the certificate is written to the card. This operation usually(?) done by the user or the admin within > > > a few minutes or days at the most. Most cards can not store arbitrary data. Could the registry (or some file on disk) > > > be used to store some information during this time? Can the minidriver change the container names in the cert store? This would allow it > > > to rename the container to match what the card driver would have chosen for it, and delete any temporary registry > > > entries added above. > > > > > > > > > On 10/6/2015 6:55 AM, Vincent Le Toux wrote: > > > > No, the Base CSP/KSP populate the cmapfile with the future name of the container before requesting it. > > > > When I want to remove one, it remove the container description in the cmapfile (to avoid a reuse) and call CardDeleteContainer. > > > > > > > > => the minidriver does not need to prepopulate this table because the Base CSP/KSP does it before genkey > > > > > > > > The term "GUID" is an abuse of language. It means "a unique identifier for container having max 39 chars", but not a GUID as a GUID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > regards, > > > > Vincent > > > > > > > > 2015-10-06 1:34 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>> <mailto:dee...@gm... <mailto:dee...@gm...> > > <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>>>>: > > > > > > > >https://msdn.microsoft.com/en-us/library/windows/hardware/dn468709(v=vs.85).aspx > > > > > > > > Says: "For a new container, the Base CSP/KSP selects the next container or a previously vacated one. > > > > A container can be vacated by setting the GUID information in the mscp\Map file to zero for that index." > > > > > > > > Does the minidriver need to pre-populate the table before a key gen? > > > > > > > > I brought up the PIV, because it is an example of Microsoft not using real GUIDs. > > > > and the PIV is read only, intended to be issued by a CMS by a central authority. > > > > > > > > The OpenSC PIV driver could be loaded, but since Microsoft provides a driver, most people will not use > > > > OpenSC for the PIV. > > > > > > > > On 10/5/2015 4:00 PM, Vincent Le Toux wrote: > > > > > Yes I know it is a unique 39 char string. > > > > > I reused the term guid because that's what written in the code & in the microsoft specification. > > > > > > > > > > When you are using the certificate enrollment process, Windows create container (and a key) having a name like: le-SmartcardLogonECC-aa85e03c-faa-07442 > > > > > (name+template+guid). It is the responsibility of the requester to set a unique container name (typically using a guid). > > > > > But when it wants to save the certificate, it reopens the container and then fails (because this specific name couldn't be found in the cmapfile because it has been replaced with another name) > > > > > > > > > > The PIV cards are not loaded by the OpenSC minidriver and I thing, could be considered as read only cards. > > > > > > > > > > => how can I solve the certificate enrollment process for read write cards ? > > > > > > > > > > Vincent > > > > > > > > > > > > > > > > > > > > > > > > > 2015-10-05 22:04 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... > <mailto:dee...@gm...>>> <mailto:dee...@gm... <mailto:dee...@gm...> > > <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>>> > <mailto:dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>> > > > <mailto:dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>> <mailto:dee...@gm... <mailto:dee...@gm...> > <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>>>>>: > > > > > > > > > > There were many e-mail around April 2011. The term "GUID" is misleading. > > > > > The "GUID" needs to be somewhat unique and based on information stored on the card. > > > > > If not already on the card A real guid could be created but must then be written to the card. > > > > > Or some other information unique on the card could be used to generate a "GUID" > > > > > > > > > > As an example, using the NIST demo card 1 with the Microsoft builtin PIV driver on Windows 7 > > > > > certutil -v -scinfo shows four certificates on the card with these Key Containers: > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc105 > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc10a > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc10b > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc101 > > > > > > > > > > The last 3 bytes are based on the NIST 800-73 table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use" > > > > > These are the BER-TLV Tag used to access the certificate objects on every card. > > > > > > > > > > The first 13 bytes are based on the FASC-N which is an agency/user ID. This is the closest thing to a card serial number > > > > > and the FASC-N is stored in the CHUID object (A CHUID on the card is required for the Microsoft drivr) > > > > > The demo card 1 has a CHUID with > > > > > FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2 > > > > > Adding spaces: > > > > > D6501858 289D 6DCA CC93 25A1685 9A46927C9D45C86501843E2 > > > > > Taken these as a DWORD, WORD, 2 bytes, 6 bytes and then revering bytes in the DWORD and WORD: > > > > > 581850d6 9d28 ca6d cc93 25a1685 > > > > > > > > > > So this is not a real GUID at all, it is a combination of part of the unique ID for the card > > > > > and object IDs of certificates objects on the card. > > > > > > > > > > The OpenSC driver card-piv.c is similar, but overlays a different byte from the FASCN with 01, 02, 03, 04 > > > > > the IDs used on the OpenSC PIV driver, so the resulting "GUID" is more unique. > > > > > > > > > > The sc_pkcs15_get_object_guid is used to return the "GUID" from the card driver based on > > > > > what the card driver can get from the card. > > > > > > > > > > On 10/5/2015 1:53 PM, Vincent Le Toux wrote: > > > > > > I'm working on the minidriver read/write mode and especially the certificate enrollment process. > > > > > > > > > > > > When a container is created on the minidriver, there is 3 ways to create the container: > > > > > > 1) > > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925 > > > > > > if md_is_guid_as_id = true; the microsoft container name is used as the id > > > > > > > > > > > > 2) > > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936 > > > > > > if > > > > > > md_is_guid_as_label = true; the microsoft container name is used as the label > > > > > > > > > > > > 3) (default) > > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868 > > > > > > the card is created with the default label "TODO: key label" > > > > > > (the microsoft container name is not used) > > > > > > > > > > > > The problem is that when the container is loaded: > > > > > > 1) if the container name is set on the card > > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501 > > > > > > Note: I didn't find in the code a place where the container name is initialized > > > > > > > > > > > > 2) (default) > > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517 > > > > > > a guid is created => the initial container name is not found anymore > > > > > > > > > > > > => when the container is created in a process, then reloaded, it fails because the container name is different > > > > > > > > > > > > > > > > > > There are many ways to solve this problem: > > > > > > A) replace the "TODO key label" with a guid and use a conversion table stored statically. > > > > > > This way, the guid for 2) is replaced at the load time > > > > > > B) set md_is_guid_as_label as default for the read write card and keep the current way to the read only cards > > > > > > .... > > > > > > > > > > > > Can you give your opinion on this ? > > > > > > (the history about that, ...) > > > > > > > > > > > > regards, > > > > > > -- > > > > > > -- > > > > > > Vincent Le Toux > > > > > > > > > > > > My Smart Logon > > > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> > <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Opensc-devel mailing list > > > > > >Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>>> > > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>>>> > > > > > >https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > -- > > > > > > > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... > <mailto:DEE...@gm...>>> <mailto:DEE...@gm... <mailto:DEE...@gm...> > > <mailto:DEE...@gm... <mailto:DEE...@gm...>> <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>>>> > <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... > <mailto:DEE...@gm...>>> > > > <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... > <mailto:DEE...@gm...>>>>>> > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > >Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>>> > > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>>>> > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > -- > > > > > Vincent Le Toux > > > > > > > > > > My Smart Logon > > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>>> > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > -- > > > > > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> <mailto:DEE...@gm... > <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>>> <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> > > <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>>>>> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>>> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > > -- > > > > -- > > > > Vincent Le Toux > > > > > > > > My Smart Logon > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > -- > > > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> <mailto:DEE...@gm... <mailto:DEE...@gm...> > <mailto:DEE...@gm... <mailto:DEE...@gm...>>>> > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > -- > > > -- > > > Vincent Le Toux > > > > > > My Smart Logon > > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > -- > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>>> > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > -- > > -- > > Vincent Le Toux > > > > My Smart Logon > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > -- > -- > Vincent Le Toux > > My Smart Logon > www.mysmartlogon.com <http://www.mysmartlogon.com/> > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2015-10-07 01:07:38
|
I see you sent the same message to the openssl-dev list yesterday, but no one has responded yet. OpenSC has a engine_pkcs11 that can do ECDSA, but no one has added ECDH yet. The main reason was that until OpenSSL-1.0.2 the routines in ECDSA_METHOD that needed to be replaced were not exposed, and it took years for the OpenSSL people to finally do something about this. They added ECDSA_METHOD_set_sign and ECDSA_METHOD_set_sign. I am afraid it might be years until the ECDH has the extra routines need to work with an engine. To get the ECDSA_METHOD changes into OpenSSL I had to get the engine working using the ecdsa/ec_locl.h header file to show what was actually needed. On 10/6/2015 12:37 PM, Alexander Gostrer wrote: > Hi Doug, > > David suggested to contact you. > We are writing an openssl ECDH engine. All private keys are in the hardware (including ephemeral keys). I found that the DH_METHOD has both (*generate_key) and (*compute_key) methods while the > ECDH_METHOD has just the (*compute_key) method. Your have the ephemeral keys in hardware? Won't that require a different ephemeral key for every active connection? A key is a key, and there is a EC_KEY_generate_key defined in ec.h, that will work for ECDSA or ECDH. But the ability to generate_key may also need to be exposed if you need to have the ephemeral keys created on the card. I have not looked at what this would take. > > We would like (once the engine is completed) to use standard SSL_accept() etc calls. But the compute_key() returns shared secret based on previously generated public/private key pair and the public > key is already sent to a peer). Is there a hook to replace the public key before it is sent out? Any ideas/plans about adding this hook into the code? Not sure how to answer this. > > Thank you, > Alex Gostrer. > > > On Tue, Oct 6, 2015 at 7:54 AM, David Woodhouse <dw...@in... <mailto:dw...@in...>> wrote: > > On Tue, 2015-10-06 at 07:52 -0700, Alexander Gostrer wrote: > > Yeah, with ECDSA we have no problems. We thought about submitting a > > patch but the code is pretty complicated and we weren't sure that we > > completely understand it. Also we wanted to stick with the stable > > version. > > You need to fix it in HEAD first. Then we can talk about backporting to > older versions. > > > Do you have Doug's email? Don't want to spam other people. > > Probably best to use the opensc mailing list. > ope...@li... <mailto:ope...@li...> > > -- > dwmw2 > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Frank M. <mo...@in...> - 2015-10-06 21:42:29
|
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 <dee...@gm...>: > > > Other developers, please answer this question about Solution #2. > > (We have a lot of old card drivers, that we should consider dropping too.) > > > > On 10/6/2015 9:50 AM, Vincent Le Toux wrote: > > > What I have understood so far about the Windows PKI, is that Windows > > create / open / save using a container name stored in memory with the same > > process (windows enrollment done immediatly) or when the > > > request is defered, get the container name by matching all the public > > keys of the card to find the right container. > > > > If I understand the above, in the deferred mode is the minidriver queried > > for all the public keys (or private?) and the minidriver then gets to > > set the container name using sc_pkcs15_get_object_guid? > > > > And in a single process mode, is the > > "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process, > > and only set when the generate key operation is done? > > If so then then you may only need to keep the mapping from > > "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver > > returns for sc_pkcs15_get_object_guid for the lipe of the session or only > > for the last keygen? i.e. you don't need to write it > > to the card, because the card would have generated a key and can now > > retrieve what it wants to use for the "GUID" using > > sc_pkcs15_get_object_guid. > > > > > > > I'm testing it tonight to be 100% sure. > > > > > > Do you know cards supported in OpenSC that can write a certificate (not > > read only) but that can't store the label ? > > > Else using the container name as label for rw cards could be the > > solution (my #2) > > > If there are any incompatible cards : > > > 1) they don't work yet so this modification won't impact them > > > 2) they can implement there own mapping logic to fix this bug > > > > > > But: > > > 1) the container name will change (and the certificate registration > > information too) > > > > If the container name will change, can the minidriver pick the name? > > > > > 2) a fallback logic needs to be implemented if some conditions are not > > meet. Typically a label too short. > > > > > > regards, > > > Vincent > > > > > > > > > 2015-10-06 16:28 GMT+02:00 Douglas E Engert <dee...@gm... <mailto: > > dee...@gm...>>: > > > > > > > > > > > > On 10/6/2015 8:20 AM, Vincent Le Toux wrote: > > > > Yes, that was my solution #1: > > > > after the key generation, retrieve the container name the way it > > would be renamed and keep in the current process memory a conversion table. > > Each time you would use the first container name, you will > > > > be able to find the OpenSC container name. > > > > This way, the first containername will be used only as a subsitute > > > > > > But if you are trying to use an external CA to sign a certificate > > request and return the certificate it may be > > > a different process at a later time that is writing the > > certificate. Could even be the next day if human intervention is needed > > > on the CA side to approve the request. > > > > > > > > > > > Solution #2 was to use the containername as a label. This way, the > > container name is saved on the card. > > > > > > Depends on the card. Most PKCS#15 would write the label. Some cards > > that emulate PKCS#15 in software > > > may generate the label each time. > > > > > > > > > > > I'm not in favour of storing informations on the computer side. > > When you are doing a smart card logon with lsass.exe, you do not have much > > access (accessing user registry is limited) > > > > > > > > > > I am not either, but for this generate a key, sign a request, send > > to CA, retrieve certificate, write certificate to card > > > the lsass would not be involved. If you cant write something to the > > card, you need to write it somewhere. > > > > > > Is there anyway to rename (or copy/delete) the container when the > > certificate is written? If so the card driver can pick the > > > container name, much as it does now for existing certificates. > > > > > > > vincent > > > > > > > > 2015-10-06 15:05 GMT+02:00 Douglas E Engert <dee...@gm... > > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > > dee...@gm...>>>: > > > > > > > > You ask: Is your message: "we want to have the same "GUID" for > > OpenSC for the PIV card than the PIV minidriver" ? > > > > > > > > NO. I don't see using the OpenSC minidriver for the PIV card, > > because Microsoft now supports the PIV. > > > > But that is something to consider, as switching drivers on a > > system could lead to the driver not finding > > > > certificates in the certificate store. > > > > They ran into the same problem of coming up with a unique key > > container. Their solution of the the last > > > > last three bytes, could lead to non unique containers on some > > systems as the last three bytes of the FASCN > > > > contain much of the uniqness in the FASCN. The OpenSC version > > replaces 1 byte in a different location > > > > that tended to be the same for all users who might share a > > computer. > > > > > > > > Well here is another idea. > > > > > > > > When a key is generated, it needs a container so it can then > > be associated with the matching certificate > > > > when the certificate is written to the card. This operation > > usually(?) done by the user or the admin within > > > > a few minutes or days at the most. Most cards can not store > > arbitrary data. Could the registry (or some file on disk) > > > > be used to store some information during this time? Can the > > minidriver change the container names in the cert store? This would allow it > > > > to rename the container to match what the card driver would > > have chosen for it, and delete any temporary registry > > > > entries added above. > > > > > > > > > > > > On 10/6/2015 6:55 AM, Vincent Le Toux wrote: > > > > > No, the Base CSP/KSP populate the cmapfile with the future > > name of the container before requesting it. > > > > > When I want to remove one, it remove the container > > description in the cmapfile (to avoid a reuse) and call CardDeleteContainer. > > > > > > > > > > => the minidriver does not need to prepopulate this table > > because the Base CSP/KSP does it before genkey > > > > > > > > > > The term "GUID" is an abuse of language. It means "a unique > > identifier for container having max 39 chars", but not a GUID as a GUID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > regards, > > > > > Vincent > > > > > > > > > > 2015-10-06 1:34 GMT+02:00 Douglas E Engert < > > dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... > > <mailto:dee...@gm...>> <mailto:dee...@gm... > > > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > > dee...@gm...>>>>: > > > > > > > > > > > > https://msdn.microsoft.com/en-us/library/windows/hardware/dn468709(v=vs.85).aspx > > > > > > > > > > Says: "For a new container, the Base CSP/KSP selects the > > next container or a previously vacated one. > > > > > A container can be vacated by setting the GUID > > information in the mscp\Map file to zero for that index." > > > > > > > > > > Does the minidriver need to pre-populate the table > > before a key gen? > > > > > > > > > > I brought up the PIV, because it is an example of > > Microsoft not using real GUIDs. > > > > > and the PIV is read only, intended to be issued by a CMS > > by a central authority. > > > > > > > > > > The OpenSC PIV driver could be loaded, but since > > Microsoft provides a driver, most people will not use > > > > > OpenSC for the PIV. > > > > > > > > > > On 10/5/2015 4:00 PM, Vincent Le Toux wrote: > > > > > > Yes I know it is a unique 39 char string. > > > > > > I reused the term guid because that's what written in > > the code & in the microsoft specification. > > > > > > > > > > > > When you are using the certificate enrollment process, > > Windows create container (and a key) having a name like: > > le-SmartcardLogonECC-aa85e03c-faa-07442 > > > > > > (name+template+guid). It is the responsibility of the > > requester to set a unique container name (typically using a guid). > > > > > > But when it wants to save the certificate, it reopens > > the container and then fails (because this specific name couldn't be found > > in the cmapfile because it has been replaced with another name) > > > > > > > > > > > > The PIV cards are not loaded by the OpenSC minidriver > > and I thing, could be considered as read only cards. > > > > > > > > > > > > => how can I solve the certificate enrollment process > > for read write cards ? > > > > > > > > > > > > Vincent > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2015-10-05 22:04 GMT+02:00 Douglas E Engert < > > dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... > > <mailto:dee...@gm...>> <mailto:dee...@gm... > > > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > > dee...@gm...>>> <mailto:dee...@gm... <mailto: > > dee...@gm...> > > > > <mailto:dee...@gm... <mailto:dee...@gm...>> > > <mailto:dee...@gm... <mailto:dee...@gm...> <mailto: > > dee...@gm... <mailto:dee...@gm...>>>>>: > > > > > > > > > > > > There were many e-mail around April 2011. The > > term "GUID" is misleading. > > > > > > The "GUID" needs to be somewhat unique and > > based on information stored on the card. > > > > > > If not already on the card A real guid could be > > created but must then be written to the card. > > > > > > Or some other information unique on the card > > could be used to generate a "GUID" > > > > > > > > > > > > As an example, using the NIST demo card 1 with > > the Microsoft builtin PIV driver on Windows 7 > > > > > > certutil -v -scinfo shows four certificates on > > the card with these Key Containers: > > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc105 > > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc10a > > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc10b > > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc101 > > > > > > > > > > > > The last 3 bytes are based on the NIST 800-73 > > table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use" > > > > > > These are the BER-TLV Tag used to access the > > certificate objects on every card. > > > > > > > > > > > > The first 13 bytes are based on the FASC-N > > which is an agency/user ID. This is the closest thing to a card serial > > number > > > > > > and the FASC-N is stored in the CHUID object (A > > CHUID on the card is required for the Microsoft drivr) > > > > > > The demo card 1 has a CHUID with > > > > > > > > FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2 > > > > > > Adding spaces: > > > > > > D6501858 289D 6DCA CC93 25A1685 > > 9A46927C9D45C86501843E2 > > > > > > Taken these as a DWORD, WORD, 2 bytes, 6 bytes > > and then revering bytes in the DWORD and WORD: > > > > > > 581850d6 9d28 ca6d cc93 25a1685 > > > > > > > > > > > > So this is not a real GUID at all, it is a > > combination of part of the unique ID for the card > > > > > > and object IDs of certificates objects on the > > card. > > > > > > > > > > > > The OpenSC driver card-piv.c is similar, but > > overlays a different byte from the FASCN with 01, 02, 03, 04 > > > > > > the IDs used on the OpenSC PIV driver, so the > > resulting "GUID" is more unique. > > > > > > > > > > > > The sc_pkcs15_get_object_guid is used to return > > the "GUID" from the card driver based on > > > > > > what the card driver can get from the card. > > > > > > > > > > > > On 10/5/2015 1:53 PM, Vincent Le Toux wrote: > > > > > > > I'm working on the minidriver read/write > > mode and especially the certificate enrollment process. > > > > > > > > > > > > > > When a container is created on the > > minidriver, there is 3 ways to create the container: > > > > > > > 1) > > > > > > > cf > > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925 > > > > > > > if md_is_guid_as_id = true; the microsoft > > container name is used as the id > > > > > > > > > > > > > > 2) > > > > > > > cf > > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936 > > > > > > > if > > > > > > > md_is_guid_as_label = true; the microsoft > > container name is used as the label > > > > > > > > > > > > > > 3) (default) > > > > > > > cf > > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868 > > > > > > > the card is created with the default label > > "TODO: key label" > > > > > > > (the microsoft container name is not used) > > > > > > > > > > > > > > The problem is that when the container is > > loaded: > > > > > > > 1) if the container name is set on the card > > > > > > > cf > > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501 > > > > > > > Note: I didn't find in the code a place > > where the container name is initialized > > > > > > > > > > > > > > 2) (default) > > > > > > > cf > > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517 > > > > > > > a guid is created => the initial container > > name is not found anymore > > > > > > > > > > > > > > => when the container is created in a > > process, then reloaded, it fails because the container name is different > > > > > > > > > > > > > > > > > > > > > There are many ways to solve this problem: > > > > > > > A) replace the "TODO key label" with a guid > > and use a conversion table stored statically. > > > > > > > This way, the guid for 2) is replaced at the > > load time > > > > > > > B) set md_is_guid_as_label as default for > > the read write card and keep the current way to the read only cards > > > > > > > .... > > > > > > > > > > > > > > Can you give your opinion on this ? > > > > > > > (the history about that, ...) > > > > > > > > > > > > > > regards, > > > > > > > -- > > > > > > > -- > > > > > > > Vincent Le Toux > > > > > > > > > > > > > > My Smart Logon > > > > > > > www.mysmartlogon.com < > > http://www.mysmartlogon.com> <http://www.mysmartlogon.com> < > > http://www.mysmartlogon.com> <http://www.mysmartlogon.com> < > > http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Opensc-devel mailing list > > > > > > >Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>> > > > <mailto:Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>>> > > > > <mailto:Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>> > > > <mailto:Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>>>> > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Douglas E. Engert <DEE...@gm... > > <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto: > > DEE...@gm...>> <mailto:DEE...@gm... > > > <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto: > > DEE...@gm...>>> <mailto:DEE...@gm... <mailto: > > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm... > > >> > > > > <mailto:DEE...@gm... <mailto:DEE...@gm...> > > <mailto:DEE...@gm... <mailto:DEE...@gm...>>>>> > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > > > > Opensc-devel mailing list > > > > > >Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>> > > > <mailto:Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>>> > > > > <mailto:Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>> > > > <mailto:Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>>>> > > > > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > -- > > > > > > Vincent Le Toux > > > > > > > > > > > > My Smart Logon > > > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> > > <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> < > > http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Opensc-devel mailing list > > > > > > Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>> > > > <mailto:Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>>> > > > > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > -- > > > > > > > > > > Douglas E. Engert <DEE...@gm... <mailto: > > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> > > <mailto:DEE...@gm... <mailto:DEE...@gm...> > > > <mailto:DEE...@gm... <mailto:DEE...@gm...>>>> > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > > Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>> > > > <mailto:Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>>> > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > -- > > > > > Vincent Le Toux > > > > > > > > > > My Smart Logon > > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> < > > http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > > Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>> > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > -- > > > > > > > > Douglas E. Engert <DEE...@gm... <mailto: > > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm... > > >>> > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto: > > Ope...@li...> <mailto: > > Ope...@li... <mailto: > > Ope...@li...>> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > > -- > > > > -- > > > > Vincent Le Toux > > > > > > > > My Smart Logon > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> < > > http://www.mysmartlogon.com/> > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto: > > Ope...@li...> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > -- > > > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm... > > >> > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... <mailto: > > Ope...@li...> > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > -- > > > -- > > > Vincent Le Toux > > > > > > My Smart Logon > > > www.mysmartlogon.com <http://www.mysmartlogon.com/> > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > -- > > > > Douglas E. Engert <DEE...@gm...> > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > -- > -- > Vincent Le Toux > > My Smart Logon > www.mysmartlogon.com > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > 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 |
|
From: Vincent Le T. <vin...@my...> - 2015-10-06 17:38:24
|
FYI To test ADCS manual certificate issuance with smart card: Uncheck "Allow private key to be exported" (took me a while to find this) Check "CA certificate manager approval" When doing having a pending request, the certificate request is also saved on the smart card. It can be found later to determine the container. => the container name like "le-SmartcardLogonECC-aa85e03c-faa-07442" seems to live only during the process life and a mapping may be a solution I don't understand the question "If the container name will change, can the minidriver pick the name?" But I meant to say is if the minidriver is changed, the certificate registered on the user certificate store will become invalid because the private key won't be found. Additionally the certificate propagation service may add the certificate twice (one with the old container name, one with the new container name) => ok, I'll see how a mapping can be done between the OpenSC container name and the minidriver one regards, Vincent 2015-10-06 17:25 GMT+02:00 Douglas E Engert <dee...@gm...>: > Other developers, please answer this question about Solution #2. > (We have a lot of old card drivers, that we should consider dropping too.) > > On 10/6/2015 9:50 AM, Vincent Le Toux wrote: > > What I have understood so far about the Windows PKI, is that Windows > create / open / save using a container name stored in memory with the same > process (windows enrollment done immediatly) or when the > > request is defered, get the container name by matching all the public > keys of the card to find the right container. > > If I understand the above, in the deferred mode is the minidriver queried > for all the public keys (or private?) and the minidriver then gets to > set the container name using sc_pkcs15_get_object_guid? > > And in a single process mode, is the > "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process, > and only set when the generate key operation is done? > If so then then you may only need to keep the mapping from > "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver > returns for sc_pkcs15_get_object_guid for the lipe of the session or only > for the last keygen? i.e. you don't need to write it > to the card, because the card would have generated a key and can now > retrieve what it wants to use for the "GUID" using > sc_pkcs15_get_object_guid. > > > > I'm testing it tonight to be 100% sure. > > > > Do you know cards supported in OpenSC that can write a certificate (not > read only) but that can't store the label ? > > Else using the container name as label for rw cards could be the > solution (my #2) > > If there are any incompatible cards : > > 1) they don't work yet so this modification won't impact them > > 2) they can implement there own mapping logic to fix this bug > > > > But: > > 1) the container name will change (and the certificate registration > information too) > > If the container name will change, can the minidriver pick the name? > > > 2) a fallback logic needs to be implemented if some conditions are not > meet. Typically a label too short. > > > > regards, > > Vincent > > > > > > 2015-10-06 16:28 GMT+02:00 Douglas E Engert <dee...@gm... <mailto: > dee...@gm...>>: > > > > > > > > On 10/6/2015 8:20 AM, Vincent Le Toux wrote: > > > Yes, that was my solution #1: > > > after the key generation, retrieve the container name the way it > would be renamed and keep in the current process memory a conversion table. > Each time you would use the first container name, you will > > > be able to find the OpenSC container name. > > > This way, the first containername will be used only as a subsitute > > > > But if you are trying to use an external CA to sign a certificate > request and return the certificate it may be > > a different process at a later time that is writing the > certificate. Could even be the next day if human intervention is needed > > on the CA side to approve the request. > > > > > > > > Solution #2 was to use the containername as a label. This way, the > container name is saved on the card. > > > > Depends on the card. Most PKCS#15 would write the label. Some cards > that emulate PKCS#15 in software > > may generate the label each time. > > > > > > > > I'm not in favour of storing informations on the computer side. > When you are doing a smart card logon with lsass.exe, you do not have much > access (accessing user registry is limited) > > > > > > > I am not either, but for this generate a key, sign a request, send > to CA, retrieve certificate, write certificate to card > > the lsass would not be involved. If you cant write something to the > card, you need to write it somewhere. > > > > Is there anyway to rename (or copy/delete) the container when the > certificate is written? If so the card driver can pick the > > container name, much as it does now for existing certificates. > > > > > vincent > > > > > > 2015-10-06 15:05 GMT+02:00 Douglas E Engert <dee...@gm... > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > dee...@gm...>>>: > > > > > > You ask: Is your message: "we want to have the same "GUID" for > OpenSC for the PIV card than the PIV minidriver" ? > > > > > > NO. I don't see using the OpenSC minidriver for the PIV card, > because Microsoft now supports the PIV. > > > But that is something to consider, as switching drivers on a > system could lead to the driver not finding > > > certificates in the certificate store. > > > They ran into the same problem of coming up with a unique key > container. Their solution of the the last > > > last three bytes, could lead to non unique containers on some > systems as the last three bytes of the FASCN > > > contain much of the uniqness in the FASCN. The OpenSC version > replaces 1 byte in a different location > > > that tended to be the same for all users who might share a > computer. > > > > > > Well here is another idea. > > > > > > When a key is generated, it needs a container so it can then > be associated with the matching certificate > > > when the certificate is written to the card. This operation > usually(?) done by the user or the admin within > > > a few minutes or days at the most. Most cards can not store > arbitrary data. Could the registry (or some file on disk) > > > be used to store some information during this time? Can the > minidriver change the container names in the cert store? This would allow it > > > to rename the container to match what the card driver would > have chosen for it, and delete any temporary registry > > > entries added above. > > > > > > > > > On 10/6/2015 6:55 AM, Vincent Le Toux wrote: > > > > No, the Base CSP/KSP populate the cmapfile with the future > name of the container before requesting it. > > > > When I want to remove one, it remove the container > description in the cmapfile (to avoid a reuse) and call CardDeleteContainer. > > > > > > > > => the minidriver does not need to prepopulate this table > because the Base CSP/KSP does it before genkey > > > > > > > > The term "GUID" is an abuse of language. It means "a unique > identifier for container having max 39 chars", but not a GUID as a GUID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > regards, > > > > Vincent > > > > > > > > 2015-10-06 1:34 GMT+02:00 Douglas E Engert < > dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... > <mailto:dee...@gm...>> <mailto:dee...@gm... > > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > dee...@gm...>>>>: > > > > > > > > > https://msdn.microsoft.com/en-us/library/windows/hardware/dn468709(v=vs.85).aspx > > > > > > > > Says: "For a new container, the Base CSP/KSP selects the > next container or a previously vacated one. > > > > A container can be vacated by setting the GUID > information in the mscp\Map file to zero for that index." > > > > > > > > Does the minidriver need to pre-populate the table > before a key gen? > > > > > > > > I brought up the PIV, because it is an example of > Microsoft not using real GUIDs. > > > > and the PIV is read only, intended to be issued by a CMS > by a central authority. > > > > > > > > The OpenSC PIV driver could be loaded, but since > Microsoft provides a driver, most people will not use > > > > OpenSC for the PIV. > > > > > > > > On 10/5/2015 4:00 PM, Vincent Le Toux wrote: > > > > > Yes I know it is a unique 39 char string. > > > > > I reused the term guid because that's what written in > the code & in the microsoft specification. > > > > > > > > > > When you are using the certificate enrollment process, > Windows create container (and a key) having a name like: > le-SmartcardLogonECC-aa85e03c-faa-07442 > > > > > (name+template+guid). It is the responsibility of the > requester to set a unique container name (typically using a guid). > > > > > But when it wants to save the certificate, it reopens > the container and then fails (because this specific name couldn't be found > in the cmapfile because it has been replaced with another name) > > > > > > > > > > The PIV cards are not loaded by the OpenSC minidriver > and I thing, could be considered as read only cards. > > > > > > > > > > => how can I solve the certificate enrollment process > for read write cards ? > > > > > > > > > > Vincent > > > > > > > > > > > > > > > > > > > > > > > > > 2015-10-05 22:04 GMT+02:00 Douglas E Engert < > dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... > <mailto:dee...@gm...>> <mailto:dee...@gm... > > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto: > dee...@gm...>>> <mailto:dee...@gm... <mailto: > dee...@gm...> > > > <mailto:dee...@gm... <mailto:dee...@gm...>> > <mailto:dee...@gm... <mailto:dee...@gm...> <mailto: > dee...@gm... <mailto:dee...@gm...>>>>>: > > > > > > > > > > There were many e-mail around April 2011. The > term "GUID" is misleading. > > > > > The "GUID" needs to be somewhat unique and > based on information stored on the card. > > > > > If not already on the card A real guid could be > created but must then be written to the card. > > > > > Or some other information unique on the card > could be used to generate a "GUID" > > > > > > > > > > As an example, using the NIST demo card 1 with > the Microsoft builtin PIV driver on Windows 7 > > > > > certutil -v -scinfo shows four certificates on > the card with these Key Containers: > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc105 > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc10a > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc10b > > > > > 581850d6-9d28-ca6d-cc93-25a1685fc101 > > > > > > > > > > The last 3 bytes are based on the NIST 800-73 > table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use" > > > > > These are the BER-TLV Tag used to access the > certificate objects on every card. > > > > > > > > > > The first 13 bytes are based on the FASC-N > which is an agency/user ID. This is the closest thing to a card serial > number > > > > > and the FASC-N is stored in the CHUID object (A > CHUID on the card is required for the Microsoft drivr) > > > > > The demo card 1 has a CHUID with > > > > > > FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2 > > > > > Adding spaces: > > > > > D6501858 289D 6DCA CC93 25A1685 > 9A46927C9D45C86501843E2 > > > > > Taken these as a DWORD, WORD, 2 bytes, 6 bytes > and then revering bytes in the DWORD and WORD: > > > > > 581850d6 9d28 ca6d cc93 25a1685 > > > > > > > > > > So this is not a real GUID at all, it is a > combination of part of the unique ID for the card > > > > > and object IDs of certificates objects on the > card. > > > > > > > > > > The OpenSC driver card-piv.c is similar, but > overlays a different byte from the FASCN with 01, 02, 03, 04 > > > > > the IDs used on the OpenSC PIV driver, so the > resulting "GUID" is more unique. > > > > > > > > > > The sc_pkcs15_get_object_guid is used to return > the "GUID" from the card driver based on > > > > > what the card driver can get from the card. > > > > > > > > > > On 10/5/2015 1:53 PM, Vincent Le Toux wrote: > > > > > > I'm working on the minidriver read/write > mode and especially the certificate enrollment process. > > > > > > > > > > > > When a container is created on the > minidriver, there is 3 ways to create the container: > > > > > > 1) > > > > > > cf > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925 > > > > > > if md_is_guid_as_id = true; the microsoft > container name is used as the id > > > > > > > > > > > > 2) > > > > > > cf > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936 > > > > > > if > > > > > > md_is_guid_as_label = true; the microsoft > container name is used as the label > > > > > > > > > > > > 3) (default) > > > > > > cf > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868 > > > > > > the card is created with the default label > "TODO: key label" > > > > > > (the microsoft container name is not used) > > > > > > > > > > > > The problem is that when the container is > loaded: > > > > > > 1) if the container name is set on the card > > > > > > cf > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501 > > > > > > Note: I didn't find in the code a place > where the container name is initialized > > > > > > > > > > > > 2) (default) > > > > > > cf > https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517 > > > > > > a guid is created => the initial container > name is not found anymore > > > > > > > > > > > > => when the container is created in a > process, then reloaded, it fails because the container name is different > > > > > > > > > > > > > > > > > > There are many ways to solve this problem: > > > > > > A) replace the "TODO key label" with a guid > and use a conversion table stored statically. > > > > > > This way, the guid for 2) is replaced at the > load time > > > > > > B) set md_is_guid_as_label as default for > the read write card and keep the current way to the read only cards > > > > > > .... > > > > > > > > > > > > Can you give your opinion on this ? > > > > > > (the history about that, ...) > > > > > > > > > > > > regards, > > > > > > -- > > > > > > -- > > > > > > Vincent Le Toux > > > > > > > > > > > > My Smart Logon > > > > > > www.mysmartlogon.com < > http://www.mysmartlogon.com> <http://www.mysmartlogon.com> < > http://www.mysmartlogon.com> <http://www.mysmartlogon.com> < > http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Opensc-devel mailing list > > > > > >Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>> > > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>>> > > > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > -- > > > > > > > > > > Douglas E. Engert <DEE...@gm... > <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto: > DEE...@gm...>> <mailto:DEE...@gm... > > <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto: > DEE...@gm...>>> <mailto:DEE...@gm... <mailto: > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm... > >> > > > <mailto:DEE...@gm... <mailto:DEE...@gm...> > <mailto:DEE...@gm... <mailto:DEE...@gm...>>>>> > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > >Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>> > > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>>> > > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > -- > > > > > Vincent Le Toux > > > > > > > > > > My Smart Logon > > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> > <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> < > http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > > Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>> > > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > -- > > > > > > > > Douglas E. Engert <DEE...@gm... <mailto: > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> > <mailto:DEE...@gm... <mailto:DEE...@gm...> > > <mailto:DEE...@gm... <mailto:DEE...@gm...>>>> > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > <mailto:Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>>> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > > -- > > > > -- > > > > Vincent Le Toux > > > > > > > > My Smart Logon > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> < > http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > -- > > > > > > Douglas E. Engert <DEE...@gm... <mailto: > DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm... > >>> > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... <mailto: > Ope...@li...> <mailto: > Ope...@li... <mailto: > Ope...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > -- > > > -- > > > Vincent Le Toux > > > > > > My Smart Logon > > > www.mysmartlogon.com <http://www.mysmartlogon.com> < > http://www.mysmartlogon.com/> > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... <mailto: > Ope...@li...> > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > -- > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm... > >> > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... <mailto: > Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > -- > > -- > > Vincent Le Toux > > > > My Smart Logon > > www.mysmartlogon.com <http://www.mysmartlogon.com/> > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm...> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
|
From: Alexander G. <ago...@gm...> - 2015-10-06 17:37:39
|
Hi Doug, David suggested to contact you. We are writing an openssl ECDH engine. All private keys are in the hardware (including ephemeral keys). I found that the DH_METHOD has both (*generate_key) and (*compute_key) methods while the ECDH_METHOD has just the (*compute_key) method. We would like (once the engine is completed) to use standard SSL_accept() etc calls. But the compute_key() returns shared secret based on previously generated public/private key pair and the public key is already sent to a peer). Is there a hook to replace the public key before it is sent out? Any ideas/plans about adding this hook into the code? Thank you, Alex Gostrer. > > On Tue, Oct 6, 2015 at 7:54 AM, David Woodhouse <dw...@in...> > wrote: > >> On Tue, 2015-10-06 at 07:52 -0700, Alexander Gostrer wrote: >> > Yeah, with ECDSA we have no problems. We thought about submitting a >> > patch but the code is pretty complicated and we weren't sure that we >> > completely understand it. Also we wanted to stick with the stable >> > version. >> >> You need to fix it in HEAD first. Then we can talk about backporting to >> older versions. >> >> > Do you have Doug's email? Don't want to spam other people. >> >> Probably best to use the opensc mailing list. >> ope...@li... >> >> -- >> dwmw2 >> >> > |
|
From: Douglas E E. <dee...@gm...> - 2015-10-06 15:33:10
|
Other developers, please answer this question about Solution #2. (We have a lot of old card drivers, that we should consider dropping too.) On 10/6/2015 9:50 AM, Vincent Le Toux wrote: > What I have understood so far about the Windows PKI, is that Windows create / open / save using a container name stored in memory with the same process (windows enrollment done immediatly) or when the > request is defered, get the container name by matching all the public keys of the card to find the right container. If I understand the above, in the deferred mode is the minidriver queried for all the public keys (or private?) and the minidriver then gets to set the container name using sc_pkcs15_get_object_guid? And in a single process mode, is the "le-SmartcardLogonECC-aa85e03c-faa-07442" only for the life of the process, and only set when the generate key operation is done? If so then then you may only need to keep the mapping from "le-SmartcardLogonECC-aa85e03c-faa-07442" to whatever the card driver returns for sc_pkcs15_get_object_guid for the lipe of the session or only for the last keygen? i.e. you don't need to write it to the card, because the card would have generated a key and can now retrieve what it wants to use for the "GUID" using sc_pkcs15_get_object_guid. > I'm testing it tonight to be 100% sure. > > Do you know cards supported in OpenSC that can write a certificate (not read only) but that can't store the label ? > Else using the container name as label for rw cards could be the solution (my #2) > If there are any incompatible cards : > 1) they don't work yet so this modification won't impact them > 2) they can implement there own mapping logic to fix this bug > > But: > 1) the container name will change (and the certificate registration information too) If the container name will change, can the minidriver pick the name? > 2) a fallback logic needs to be implemented if some conditions are not meet. Typically a label too short. > > regards, > Vincent > > > 2015-10-06 16:28 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...>>: > > > > On 10/6/2015 8:20 AM, Vincent Le Toux wrote: > > Yes, that was my solution #1: > > after the key generation, retrieve the container name the way it would be renamed and keep in the current process memory a conversion table. Each time you would use the first container name, you will > > be able to find the OpenSC container name. > > This way, the first containername will be used only as a subsitute > > But if you are trying to use an external CA to sign a certificate request and return the certificate it may be > a different process at a later time that is writing the certificate. Could even be the next day if human intervention is needed > on the CA side to approve the request. > > > > > Solution #2 was to use the containername as a label. This way, the container name is saved on the card. > > Depends on the card. Most PKCS#15 would write the label. Some cards that emulate PKCS#15 in software > may generate the label each time. > > > > > I'm not in favour of storing informations on the computer side. When you are doing a smart card logon with lsass.exe, you do not have much access (accessing user registry is limited) > > > > I am not either, but for this generate a key, sign a request, send to CA, retrieve certificate, write certificate to card > the lsass would not be involved. If you cant write something to the card, you need to write it somewhere. > > Is there anyway to rename (or copy/delete) the container when the certificate is written? If so the card driver can pick the > container name, much as it does now for existing certificates. > > > vincent > > > > 2015-10-06 15:05 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>>: > > > > You ask: Is your message: "we want to have the same "GUID" for OpenSC for the PIV card than the PIV minidriver" ? > > > > NO. I don't see using the OpenSC minidriver for the PIV card, because Microsoft now supports the PIV. > > But that is something to consider, as switching drivers on a system could lead to the driver not finding > > certificates in the certificate store. > > They ran into the same problem of coming up with a unique key container. Their solution of the the last > > last three bytes, could lead to non unique containers on some systems as the last three bytes of the FASCN > > contain much of the uniqness in the FASCN. The OpenSC version replaces 1 byte in a different location > > that tended to be the same for all users who might share a computer. > > > > Well here is another idea. > > > > When a key is generated, it needs a container so it can then be associated with the matching certificate > > when the certificate is written to the card. This operation usually(?) done by the user or the admin within > > a few minutes or days at the most. Most cards can not store arbitrary data. Could the registry (or some file on disk) > > be used to store some information during this time? Can the minidriver change the container names in the cert store? This would allow it > > to rename the container to match what the card driver would have chosen for it, and delete any temporary registry > > entries added above. > > > > > > On 10/6/2015 6:55 AM, Vincent Le Toux wrote: > > > No, the Base CSP/KSP populate the cmapfile with the future name of the container before requesting it. > > > When I want to remove one, it remove the container description in the cmapfile (to avoid a reuse) and call CardDeleteContainer. > > > > > > => the minidriver does not need to prepopulate this table because the Base CSP/KSP does it before genkey > > > > > > The term "GUID" is an abuse of language. It means "a unique identifier for container having max 39 chars", but not a GUID as a GUID. > > > > > > > > > > > > > > > > > > > > regards, > > > Vincent > > > > > > 2015-10-06 1:34 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>>>: > > > > > >https://msdn.microsoft.com/en-us/library/windows/hardware/dn468709(v=vs.85).aspx > > > > > > Says: "For a new container, the Base CSP/KSP selects the next container or a previously vacated one. > > > A container can be vacated by setting the GUID information in the mscp\Map file to zero for that index." > > > > > > Does the minidriver need to pre-populate the table before a key gen? > > > > > > I brought up the PIV, because it is an example of Microsoft not using real GUIDs. > > > and the PIV is read only, intended to be issued by a CMS by a central authority. > > > > > > The OpenSC PIV driver could be loaded, but since Microsoft provides a driver, most people will not use > > > OpenSC for the PIV. > > > > > > On 10/5/2015 4:00 PM, Vincent Le Toux wrote: > > > > Yes I know it is a unique 39 char string. > > > > I reused the term guid because that's what written in the code & in the microsoft specification. > > > > > > > > When you are using the certificate enrollment process, Windows create container (and a key) having a name like: le-SmartcardLogonECC-aa85e03c-faa-07442 > > > > (name+template+guid). It is the responsibility of the requester to set a unique container name (typically using a guid). > > > > But when it wants to save the certificate, it reopens the container and then fails (because this specific name couldn't be found in the cmapfile because it has been replaced with another name) > > > > > > > > The PIV cards are not loaded by the OpenSC minidriver and I thing, could be considered as read only cards. > > > > > > > > => how can I solve the certificate enrollment process for read write cards ? > > > > > > > > Vincent > > > > > > > > > > > > > > > > > > > > 2015-10-05 22:04 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... > <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>> <mailto:dee...@gm... <mailto:dee...@gm...> > > <mailto:dee...@gm... <mailto:dee...@gm...>> <mailto:dee...@gm... <mailto:dee...@gm...> <mailto:dee...@gm... <mailto:dee...@gm...>>>>>: > > > > > > > > There were many e-mail around April 2011. The term "GUID" is misleading. > > > > The "GUID" needs to be somewhat unique and based on information stored on the card. > > > > If not already on the card A real guid could be created but must then be written to the card. > > > > Or some other information unique on the card could be used to generate a "GUID" > > > > > > > > As an example, using the NIST demo card 1 with the Microsoft builtin PIV driver on Windows 7 > > > > certutil -v -scinfo shows four certificates on the card with these Key Containers: > > > > 581850d6-9d28-ca6d-cc93-25a1685fc105 > > > > 581850d6-9d28-ca6d-cc93-25a1685fc10a > > > > 581850d6-9d28-ca6d-cc93-25a1685fc10b > > > > 581850d6-9d28-ca6d-cc93-25a1685fc101 > > > > > > > > The last 3 bytes are based on the NIST 800-73 table 2 "Object Identifiers of the PIV Data Objects for Interoperable Use" > > > > These are the BER-TLV Tag used to access the certificate objects on every card. > > > > > > > > The first 13 bytes are based on the FASC-N which is an agency/user ID. This is the closest thing to a card serial number > > > > and the FASC-N is stored in the CHUID object (A CHUID on the card is required for the Microsoft drivr) > > > > The demo card 1 has a CHUID with > > > > FASCN=D6501858289D6DCACC9325A16859A46927C9D45C86501843E2 > > > > Adding spaces: > > > > D6501858 289D 6DCA CC93 25A1685 9A46927C9D45C86501843E2 > > > > Taken these as a DWORD, WORD, 2 bytes, 6 bytes and then revering bytes in the DWORD and WORD: > > > > 581850d6 9d28 ca6d cc93 25a1685 > > > > > > > > So this is not a real GUID at all, it is a combination of part of the unique ID for the card > > > > and object IDs of certificates objects on the card. > > > > > > > > The OpenSC driver card-piv.c is similar, but overlays a different byte from the FASCN with 01, 02, 03, 04 > > > > the IDs used on the OpenSC PIV driver, so the resulting "GUID" is more unique. > > > > > > > > The sc_pkcs15_get_object_guid is used to return the "GUID" from the card driver based on > > > > what the card driver can get from the card. > > > > > > > > On 10/5/2015 1:53 PM, Vincent Le Toux wrote: > > > > > I'm working on the minidriver read/write mode and especially the certificate enrollment process. > > > > > > > > > > When a container is created on the minidriver, there is 3 ways to create the container: > > > > > 1) > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1925 > > > > > if md_is_guid_as_id = true; the microsoft container name is used as the id > > > > > > > > > > 2) > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1936 > > > > > if > > > > > md_is_guid_as_label = true; the microsoft container name is used as the label > > > > > > > > > > 3) (default) > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1868 > > > > > the card is created with the default label "TODO: key label" > > > > > (the microsoft container name is not used) > > > > > > > > > > The problem is that when the container is loaded: > > > > > 1) if the container name is set on the card > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1501 > > > > > Note: I didn't find in the code a place where the container name is initialized > > > > > > > > > > 2) (default) > > > > > cf https://github.com/OpenSC/OpenSC/blob/master/src/minidriver/minidriver.c#L1517 > > > > > a guid is created => the initial container name is not found anymore > > > > > > > > > > => when the container is created in a process, then reloaded, it fails because the container name is different > > > > > > > > > > > > > > > There are many ways to solve this problem: > > > > > A) replace the "TODO key label" with a guid and use a conversion table stored statically. > > > > > This way, the guid for 2) is replaced at the load time > > > > > B) set md_is_guid_as_label as default for the read write card and keep the current way to the read only cards > > > > > .... > > > > > > > > > > Can you give your opinion on this ? > > > > > (the history about that, ...) > > > > > > > > > > regards, > > > > > -- > > > > > -- > > > > > Vincent Le Toux > > > > > > > > > > My Smart Logon > > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Opensc-devel mailing list > > > > >Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>>> > > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > -- > > > > > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> <mailto:DEE...@gm... > <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>>> <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> > > <mailto:DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>>>>> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > >Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>>> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > > > > > > -- > > > > -- > > > > Vincent Le Toux > > > > > > > > My Smart Logon > > > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > Opensc-devel mailing list > > > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > -- > > > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>> <mailto:DEE...@gm... <mailto:DEE...@gm...> > <mailto:DEE...@gm... <mailto:DEE...@gm...>>>> > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > <mailto:Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>>> > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > > > > > > -- > > > -- > > > Vincent Le Toux > > > > > > My Smart Logon > > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > Opensc-devel mailing list > > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > -- > > > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...> <mailto:DEE...@gm... <mailto:DEE...@gm...>>> > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... <mailto:Ope...@li...> <mailto:Ope...@li... <mailto:Ope...@li...>> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > > > -- > > -- > > Vincent Le Toux > > > > My Smart Logon > > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/> > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > -- > -- > Vincent Le Toux > > My Smart Logon > www.mysmartlogon.com <http://www.mysmartlogon.com/> > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
5 messages has been excluded from this view by a project administrator.
