From: Charlie B. <cha...@gm...> - 2013-05-15 17:11:17
|
Is there a better technique for generating the first certificate for either the 9A, 9C, 9D or 9E keys than the one described in the wiki? The pkcs11 openssl engine does not see the private key that I generated using piv-tool until after I set the certificate for the first time. I had to fall back to manually crafting the cert with bouncycastle. Once I sent down this generated cert the pkcs15-tool was able to see the public key, private key and cert properly. Any time after this point I can use the piv-tool to erase and reset the keys/certs without a problem. Could this just be a result of the cards implementation of PIV? Or is this something related to OpenSC itself do you think? Charles Bancroft Software Engineer Raytheon BBN Technologies |
From: Douglas E. E. <dee...@an...> - 2013-05-15 19:36:00
|
On 5/15/2013 12:11 PM, Charlie Bancroft wrote: > Is there a better technique for generating the first certificate for either the 9A, 9C, 9D or 9E keys than the one described in the wiki? Not really. The PIV does not store a public key on the card in its own object. It only stores the public key in a certificate. The OpenSC PIV driver emulates a public key object by reading the certificate and extracting the public key. So this is a chicken and egg dilema. The response to a keygen is the only time you will get the public key from the card. The CMS is then expected to save this public key and put it into certificate request. > The pkcs11 openssl engine does not see the private key that I > generated using piv-tool until after I set the certificate for the first time. To get around these problems, when no certificate is found on the card, the pkcs15-piv.c it will look for the environment variable that points at a file containing the public key. See the code in pkcs15-piv.c line 851 "* If we used the piv-tool to generate a key," The variable is of form PIV_9A_KEY=some file name The 9A could be 9C, 9D, 9E. The PIV tool is setup to save the key when it is generated using the -o option. Also see card-piv.c line 661 /* TODO: -DEE Could add key to cache so could use engine to generate key, * and sign req in single operation */ > I had to fall back to manually crafting the cert with bouncycastle. The piv-tool -o option has the file name ending in the keyID for example -o cards/$1.9A ($1 is a card number) In a genreq.sh one could then do: KEYID=9A PIV_9A_KEY=cards/$1.$KEYID export PIV_9A_KEY openssl << EOT engine dynamic -vvvv -pre SO_PATH:$OPENSC_ENGINE/engines/engine_pkcs11.so -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:$MODULE version req $SSLEAY_CONFIG -engine pkcs11 -keyform engine -sha1 -new -key slot_1-id_$ID -out cards/$1.myreq.$KEYID.pem -text EOT So the engine would call PKCS#11, and the code in pkjcs15-piv.c would find no certificarte, then read the name of the public key file form the env variable PIV_9A_KEY, and present it as a public key object as it it was on the card. > Once I sent down this generated cert the > pkcs15-tool was able to see the public key, private key and cert properly. Any time after this point I can use the piv-tool to erase and reset the keys/certs without a problem. > > Could this just be a result of the cards implementation of PIV? Or is this something related to OpenSC itself do you think? The NIST 800-73 specs. No public key object. The pubkey can only be read when the keypair is generated. (Some card vendors may have a way to read the pubkey, but it is not in the NIST 800-73.) The Pubkey will reside in certificate after that. > > Charles Bancroft > Software Engineer > Raytheon BBN Technologies > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |
From: Charlie B. <cha...@gm...> - 2013-05-15 20:36:47
|
Hi Douglas, I may have mis-stated the question. I have been able to generate the key without a problem. My issue is that processing the req on an uninitialized card with no previous certs it seems that the openssl pkcs11 engine cannot locate the private key corresponding to the public key previously generated. The output I see from the openssl command is: openssl << EOT engine dynamic -vvvv -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so \ -pre ID:pkcs11 -pre NO_VCHECK:1 \ -pre LIST_ADD:1 -pre LOAD \ -pre MODULE_PATH:/usr/lib/opensc-pkcs11.so version req $SSLEAY_CONFIG -engine pkcs11 -md5 -new \ -key slot_1-id_1 -keyform engine -out ./card3.piva.pem -text EOT OpenSSL> (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: NO_VCHECK:1 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/lib/opensc-pkcs11.so Loaded: (pkcs11) pkcs11 engine SO_PATH: Specifies the path to the 'pkcs11-engine' shared library (input flags): STRING MODULE_PATH: Specifies the path to the pkcs11 module shared library (input flags): STRING PIN: Specifies the pin code (input flags): STRING VERBOSE: Print additional details (input flags): NO_INPUT QUIET: Remove additional details (input flags): NO_INPUT LOAD_CERT_CTRL: Get the certificate from card (input flags): [Internal] INIT_ARGS: Specifies additional initialization arguments to the pkcs11 module (input flags): STRING OpenSSL> OpenSSL 1.0.1e 11 Feb 2013 OpenSSL> engine "pkcs11" set. No keys found. PKCS11_get_private_key returned NULL cannot load Private Key from engine 139902858352296:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:126: unable to load Private Key error in req If I hand craft the cert and load it onto the card, then the pkcs11 engine is able to see the keys, and cert and if I generate a new key and run the openssl command again it succeeds. My actual question now is: Is this openssl engine issue something that strikes you as being related to OpenSC or merely that my card is not exposing the private key properly until after the first initialization? Thanks Charles Bancroft Software Engineer Raytheon BBN Technologies On Wed, May 15, 2013 at 3:35 PM, Douglas E. Engert <dee...@an...> wrote: > > > On 5/15/2013 12:11 PM, Charlie Bancroft wrote: > > Is there a better technique for generating the first certificate for > either the 9A, 9C, 9D or 9E keys than the one described in the wiki? > > Not really. > > The PIV does not store a public key on the card in its own object. > It only stores the public key in a certificate. > > The OpenSC PIV driver emulates a public key object by reading the > certificate > and extracting the public key. > > So this is a chicken and egg dilema. > > The response to a keygen is the only time you will get the public key > from the card. The CMS is then expected to save this public key and put it > into > certificate request. > > > The pkcs11 openssl engine does not see the private key that I > > generated using piv-tool until after I set the certificate for the first > time. > > To get around these problems, when no certificate is found on the card, > the pkcs15-piv.c it will look for the environment variable that points at > a file > containing the public key. See the code in pkcs15-piv.c line 851 > "* If we used the piv-tool to generate a key," > The variable is of form PIV_9A_KEY=some file name > The 9A could be 9C, 9D, 9E. > > The PIV tool is setup to save the key when it is generated using the -o > option. > > Also see card-piv.c line 661 > /* TODO: -DEE Could add key to cache so could use > engine to generate key, > * and sign req in single operation */ > > > I had to fall back to manually crafting the cert with bouncycastle. > > The piv-tool -o option has the file name ending in the keyID > for example -o cards/$1.9A ($1 is a card number) > > In a genreq.sh one could then do: > > KEYID=9A > PIV_9A_KEY=cards/$1.$KEYID > export PIV_9A_KEY > > openssl << EOT > engine dynamic -vvvv -pre SO_PATH:$OPENSC_ENGINE/engines/engine_pkcs11.so > -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre > MODULE_PATH:$MODULE > version > req $SSLEAY_CONFIG -engine pkcs11 -keyform engine -sha1 -new -key > slot_1-id_$ID -out cards/$1.myreq.$KEYID.pem -text > > EOT > > So the engine would call PKCS#11, and the code in pkjcs15-piv.c would > find no certificarte, then read the name of the public key file > form the env variable PIV_9A_KEY, and present it as a public key object > as it it was on the card. > > > Once I sent down this generated cert the > > pkcs15-tool was able to see the public key, private key and cert > properly. Any time after this point I can use the piv-tool to erase and > reset the keys/certs without a problem. > > > > Could this just be a result of the cards implementation of PIV? Or is > this something related to OpenSC itself do you think? > > The NIST 800-73 specs. No public key object. The pubkey can only be read > when > the keypair is generated. (Some card vendors may have a way to read the > pubkey, but it > is not in the NIST 800-73.) The Pubkey will reside in certificate after > that. > > > > Charles Bancroft > > Software Engineer > > Raytheon BBN Technologies > > > > > > > ------------------------------------------------------------------------------ > > AlienVault Unified Security Management (USM) platform delivers complete > > security visibility with the essential security capabilities. Easily and > > efficiently configure, manage, and operate all of your security controls > > from a single console and one unified framework. Download a free trial. > > http://p.sf.net/sfu/alienvault_d2d > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@an...> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
From: Douglas E. E. <dee...@an...> - 2013-05-16 14:00:33
|
On 5/15/2013 3:36 PM, Charlie Bancroft wrote: > Hi Douglas, > I may have mis-stated the question. I have been able to generate the key without a problem. My issue is that processing the req on an uninitialized card with no previous certs it seems that the > openssl pkcs11 engine cannot locate the private key corresponding to the public key previously generated. The output I see from the openssl command is: > Did you add the -o option to piv-tool when you generated a keypair? Did you set and export the PIV_9*_KEY to point at the output file created bu piv-tool before you ran the command below? (* can be A, C, D, E) The reason I ask what you describe would mean your did not set the PIV_9*_KEY env variable. See comments in pkcs15-piv.c line 810 and 839. What would really help is to turn on OpenSC debugging. In opensc.conf set: debug = 7; debug_file = /tmp/opensc-debug.log; NOTE: sensitive data such as PINs, will be in the log... So only send snipits of the log. Of interest would be starting with the pkcs15-piv.c:634 ""PIV-II adding objects..." Looking for pkcs15-piv.c:727 "No cert found,i=" :815 "PIV-II adding pub keys...", :848 "No cert for this pub key i= :859 "DEE look for env" and other pkcs15-piv.c log entries after this. > openssl << EOT > engine dynamic -vvvv -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so \ > -pre ID:pkcs11 -pre NO_VCHECK:1 \ > -pre LIST_ADD:1 -pre LOAD \ > -pre MODULE_PATH:/usr/lib/opensc-pkcs11.so > version > req $SSLEAY_CONFIG -engine pkcs11 -md5 -new \ > -key slot_1-id_1 -keyform engine -out ./card3.piva.pem -text > EOT > OpenSSL> (dynamic) Dynamic engine loading support > [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so > [Success]: ID:pkcs11 > [Success]: NO_VCHECK:1 > [Success]: LIST_ADD:1 > [Success]: LOAD > [Success]: MODULE_PATH:/usr/lib/opensc-pkcs11.so > Loaded: (pkcs11) pkcs11 engine > SO_PATH: Specifies the path to the 'pkcs11-engine' shared library > (input flags): STRING > MODULE_PATH: Specifies the path to the pkcs11 module shared library > (input flags): STRING > PIN: Specifies the pin code > (input flags): STRING > VERBOSE: Print additional details > (input flags): NO_INPUT > QUIET: Remove additional details > (input flags): NO_INPUT > LOAD_CERT_CTRL: Get the certificate from card > (input flags): [Internal] > INIT_ARGS: Specifies additional initialization arguments to the pkcs11 module > (input flags): STRING > OpenSSL> OpenSSL 1.0.1e 11 Feb 2013 > OpenSSL> engine "pkcs11" set. > No keys found. > PKCS11_get_private_key returned NULL > cannot load Private Key from engine > 139902858352296:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:126: > unable to load Private Key > error in req > > If I hand craft the cert and load it onto the card, then the pkcs11 engine is able to see the keys, and cert and if I generate a new key and run the openssl command again it succeeds. > > My actual question now is: Is this openssl engine issue something that strikes you as being related to OpenSC or merely that my card is not exposing the private key properly until after the first > initialization? > > Thanks > > Charles Bancroft > Software Engineer > Raytheon BBN Technologies > > > On Wed, May 15, 2013 at 3:35 PM, Douglas E. Engert <dee...@an... <mailto:dee...@an...>> wrote: > > > > On 5/15/2013 12:11 PM, Charlie Bancroft wrote: > > Is there a better technique for generating the first certificate for either the 9A, 9C, 9D or 9E keys than the one described in the wiki? > > Not really. > > The PIV does not store a public key on the card in its own object. > It only stores the public key in a certificate. > > The OpenSC PIV driver emulates a public key object by reading the certificate > and extracting the public key. > > So this is a chicken and egg dilema. > > The response to a keygen is the only time you will get the public key > from the card. The CMS is then expected to save this public key and put it into > certificate request. > > > The pkcs11 openssl engine does not see the private key that I > > generated using piv-tool until after I set the certificate for the first time. > > To get around these problems, when no certificate is found on the card, > the pkcs15-piv.c it will look for the environment variable that points at a file > containing the public key. See the code in pkcs15-piv.c line 851 > "* If we used the piv-tool to generate a key," > The variable is of form PIV_9A_KEY=some file name > The 9A could be 9C, 9D, 9E. > > The PIV tool is setup to save the key when it is generated using the -o option. > > Also see card-piv.c line 661 > /* TODO: -DEE Could add key to cache so could use engine to generate key, > * and sign req in single operation */ > > > I had to fall back to manually crafting the cert with bouncycastle. > > The piv-tool -o option has the file name ending in the keyID > for example -o cards/$1.9A ($1 is a card number) > > In a genreq.sh one could then do: > > KEYID=9A > PIV_9A_KEY=cards/$1.$KEYID > export PIV_9A_KEY > > openssl << EOT > engine dynamic -vvvv -pre SO_PATH:$OPENSC_ENGINE/engines/engine_pkcs11.so -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:$MODULE > version > req $SSLEAY_CONFIG -engine pkcs11 -keyform engine -sha1 -new -key slot_1-id_$ID -out cards/$1.myreq.$KEYID.pem -text > > EOT > > So the engine would call PKCS#11, and the code in pkjcs15-piv.c would > find no certificarte, then read the name of the public key file > form the env variable PIV_9A_KEY, and present it as a public key object > as it it was on the card. > > > Once I sent down this generated cert the > > pkcs15-tool was able to see the public key, private key and cert properly. Any time after this point I can use the piv-tool to erase and reset the keys/certs without a problem. > > > > Could this just be a result of the cards implementation of PIV? Or is this something related to OpenSC itself do you think? > > The NIST 800-73 specs. No public key object. The pubkey can only be read when > the keypair is generated. (Some card vendors may have a way to read the pubkey, but it > is not in the NIST 800-73.) The Pubkey will reside in certificate after that. > > > > Charles Bancroft > > Software Engineer > > Raytheon BBN Technologies > > > > > > ------------------------------------------------------------------------------ > > AlienVault Unified Security Management (USM) platform delivers complete > > security visibility with the essential security capabilities. Easily and > > efficiently configure, manage, and operate all of your security controls > > from a single console and one unified framework. Download a free trial. > > http://p.sf.net/sfu/alienvault_d2d > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@an... <mailto:DEE...@an...>> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 <tel:%28630%29%20252-5444> > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Opensc-devel mailing list > Ope...@li... <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |
From: Charlie B. <cha...@gm...> - 2013-05-16 14:28:29
|
Hrmm, I generated the key with the -o option and I am definitely getting properly formed public key responses from the card, but I think I may be setting the wrong env variable. Let me try again with the PIV_9*_KEY variable set. I was using the PIV_9A06_KEY as described in the wiki, and it looks like that information may be incorrect. I will let you know how it works. If it doesn't work as expected, I will follow up with logging information for you as well. Thanks again for the help Charles Bancroft Software Engineer Raytheon BBN Technologies On Thu, May 16, 2013 at 10:00 AM, Douglas E. Engert <dee...@an...>wrote: > > > On 5/15/2013 3:36 PM, Charlie Bancroft wrote: > >> Hi Douglas, >> I may have mis-stated the question. I have been able to generate the key >> without a problem. My issue is that processing the req on an uninitialized >> card with no previous certs it seems that the >> openssl pkcs11 engine cannot locate the private key corresponding to the >> public key previously generated. The output I see from the openssl command >> is: >> >> > Did you add the -o option to piv-tool when you generated a keypair? > > Did you set and export the PIV_9*_KEY to point at the output file > created bu piv-tool before you ran the command below? > (* can be A, C, D, E) > > > The reason I ask what you describe would mean your did not set the > PIV_9*_KEY > env variable. See comments in pkcs15-piv.c line 810 and 839. > > What would really help is to turn on OpenSC debugging. > In opensc.conf set: > debug = 7; > debug_file = /tmp/opensc-debug.log; > > NOTE: sensitive data such as PINs, will be in the log... > So only send snipits of the log. > > Of interest would be starting with the pkcs15-piv.c:634 ""PIV-II adding > objects..." > > Looking for pkcs15-piv.c:727 "No cert found,i=" > :815 "PIV-II adding pub keys...", > :848 "No cert for this pub key i= > :859 "DEE look for env" > > and other pkcs15-piv.c log entries after this. > > > > openssl << EOT >> engine dynamic -vvvv -pre SO_PATH:/usr/lib/engines/**engine_pkcs11.so \ >> -pre ID:pkcs11 -pre NO_VCHECK:1 \ >> -pre LIST_ADD:1 -pre LOAD \ >> -pre MODULE_PATH:/usr/lib/opensc-**pkcs11.so >> version >> req $SSLEAY_CONFIG -engine pkcs11 -md5 -new \ >> -key slot_1-id_1 -keyform engine -out ./card3.piva.pem -text >> EOT >> OpenSSL> (dynamic) Dynamic engine loading support >> [Success]: SO_PATH:/usr/lib/engines/**engine_pkcs11.so >> [Success]: ID:pkcs11 >> [Success]: NO_VCHECK:1 >> [Success]: LIST_ADD:1 >> [Success]: LOAD >> [Success]: MODULE_PATH:/usr/lib/opensc-**pkcs11.so >> Loaded: (pkcs11) pkcs11 engine >> SO_PATH: Specifies the path to the 'pkcs11-engine' shared library >> (input flags): STRING >> MODULE_PATH: Specifies the path to the pkcs11 module shared library >> (input flags): STRING >> PIN: Specifies the pin code >> (input flags): STRING >> VERBOSE: Print additional details >> (input flags): NO_INPUT >> QUIET: Remove additional details >> (input flags): NO_INPUT >> LOAD_CERT_CTRL: Get the certificate from card >> (input flags): [Internal] >> INIT_ARGS: Specifies additional initialization arguments to the >> pkcs11 module >> (input flags): STRING >> OpenSSL> OpenSSL 1.0.1e 11 Feb 2013 >> OpenSSL> engine "pkcs11" set. >> No keys found. >> PKCS11_get_private_key returned NULL >> cannot load Private Key from engine >> 139902858352296:error:**26096080:engine routines:ENGINE_load_private_**key:failed >> loading private key:eng_pkey.c:126: >> unable to load Private Key >> error in req >> >> If I hand craft the cert and load it onto the card, then the pkcs11 >> engine is able to see the keys, and cert and if I generate a new key and >> run the openssl command again it succeeds. >> >> My actual question now is: Is this openssl engine issue something that >> strikes you as being related to OpenSC or merely that my card is not >> exposing the private key properly until after the first >> initialization? >> >> Thanks >> >> Charles Bancroft >> Software Engineer >> Raytheon BBN Technologies >> >> >> On Wed, May 15, 2013 at 3:35 PM, Douglas E. Engert <dee...@an...<mailto: >> dee...@an...>> wrote: >> >> >> >> On 5/15/2013 12:11 PM, Charlie Bancroft wrote: >> > Is there a better technique for generating the first certificate >> for either the 9A, 9C, 9D or 9E keys than the one described in the wiki? >> >> Not really. >> >> The PIV does not store a public key on the card in its own object. >> It only stores the public key in a certificate. >> >> The OpenSC PIV driver emulates a public key object by reading the >> certificate >> and extracting the public key. >> >> So this is a chicken and egg dilema. >> >> The response to a keygen is the only time you will get the public key >> from the card. The CMS is then expected to save this public key and >> put it into >> certificate request. >> >> > The pkcs11 openssl engine does not see the private key that I >> > generated using piv-tool until after I set the certificate for the >> first time. >> >> To get around these problems, when no certificate is found on the >> card, >> the pkcs15-piv.c it will look for the environment variable that >> points at a file >> containing the public key. See the code in pkcs15-piv.c line 851 >> "* If we used the piv-tool to generate a key," >> The variable is of form PIV_9A_KEY=some file name >> The 9A could be 9C, 9D, 9E. >> >> The PIV tool is setup to save the key when it is generated using the >> -o option. >> >> Also see card-piv.c line 661 >> /* TODO: -DEE Could add key to cache so could >> use engine to generate key, >> * and sign req in single operation */ >> >> > I had to fall back to manually crafting the cert with bouncycastle. >> >> The piv-tool -o option has the file name ending in the keyID >> for example -o cards/$1.9A ($1 is a card number) >> >> In a genreq.sh one could then do: >> >> KEYID=9A >> PIV_9A_KEY=cards/$1.$KEYID >> export PIV_9A_KEY >> >> openssl << EOT >> engine dynamic -vvvv -pre SO_PATH:$OPENSC_ENGINE/**engines/engine_pkcs11.so >> -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre >> MODULE_PATH:$MODULE >> version >> req $SSLEAY_CONFIG -engine pkcs11 -keyform engine -sha1 -new -key >> slot_1-id_$ID -out cards/$1.myreq.$KEYID.pem -text >> >> EOT >> >> So the engine would call PKCS#11, and the code in pkjcs15-piv.c would >> find no certificarte, then read the name of the public key file >> form the env variable PIV_9A_KEY, and present it as a public key >> object >> as it it was on the card. >> >> > Once I sent down this generated cert the >> > pkcs15-tool was able to see the public key, private key and cert >> properly. Any time after this point I can use the piv-tool to erase and >> reset the keys/certs without a problem. >> > >> > Could this just be a result of the cards implementation of PIV? >> Or is this something related to OpenSC itself do you think? >> >> The NIST 800-73 specs. No public key object. The pubkey can only be >> read when >> the keypair is generated. (Some card vendors may have a way to read >> the pubkey, but it >> is not in the NIST 800-73.) The Pubkey will reside in certificate >> after that. >> > >> > Charles Bancroft >> > Software Engineer >> > Raytheon BBN Technologies >> > >> > >> > ------------------------------**------------------------------** >> ------------------ >> > AlienVault Unified Security Management (USM) platform delivers >> complete >> > security visibility with the essential security capabilities. >> Easily and >> > efficiently configure, manage, and operate all of your security >> controls >> > from a single console and one unified framework. Download a free >> trial. >> > http://p.sf.net/sfu/**alienvault_d2d<http://p.sf.net/sfu/alienvault_d2d> >> > >> > >> > >> > ______________________________**_________________ >> > Opensc-devel mailing list >> > Opensc-devel@lists.**sourceforge.net<Ope...@li...><mailto: >> Opensc-devel@lists.**sourceforge.net <Ope...@li...> >> > >> > https://lists.sourceforge.net/**lists/listinfo/opensc-devel<https://lists.sourceforge.net/lists/listinfo/opensc-devel> >> > >> >> -- >> >> Douglas E. Engert <DEE...@an... <mailto:DEE...@an...>> >> >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 <tel:%28630%29%20252-5444> >> >> >> ------------------------------**------------------------------** >> ------------------ >> AlienVault Unified Security Management (USM) platform delivers >> complete >> security visibility with the essential security capabilities. Easily >> and >> efficiently configure, manage, and operate all of your security >> controls >> from a single console and one unified framework. Download a free >> trial. >> http://p.sf.net/sfu/**alienvault_d2d<http://p.sf.net/sfu/alienvault_d2d> >> ______________________________**_________________ >> Opensc-devel mailing list >> Opensc-devel@lists.**sourceforge.net<Ope...@li...><mailto: >> Opensc-devel@lists.**sourceforge.net <Ope...@li...> >> > >> https://lists.sourceforge.net/**lists/listinfo/opensc-devel<https://lists.sourceforge.net/lists/listinfo/opensc-devel> >> >> >> > -- > > Douglas E. Engert <DEE...@an...> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > |
From: Douglas E. E. <dee...@an...> - 2013-05-16 15:23:30
|
On 5/16/2013 9:28 AM, Charlie Bancroft wrote: > Hrmm, > I generated the key with the -o option and I am definitely getting properly formed public key responses from the card, but I think I may be setting the wrong env variable. > Let me try again with the PIV_9*_KEY variable set. I was using the PIV_9A06_KEY as described in the wiki, and it looks like that information may be incorrect. I will let you know how it works. If > it doesn't work as expected, I will follow up with logging information for you as well. > Yes it looks like a documentation issue! At one time it was the kefref and type 9A06 the 9A key of type 06 - RSA 1024. Iin 0.12 or was it 0.13 it was change to the keyref only as PIV_XX_KEY as there can only be one key for each keyref, and there is no way to tell what type and size of key it is until the pkcs15-piv.c reads the file. (0.13 supports RSA and EC keys as per NIST.) > Thanks again for the help > > Charles Bancroft > Software Engineer > Raytheon BBN Technologies > > > On Thu, May 16, 2013 at 10:00 AM, Douglas E. Engert <dee...@an... <mailto:dee...@an...>> wrote: > > > > On 5/15/2013 3:36 PM, Charlie Bancroft wrote: > > Hi Douglas, > I may have mis-stated the question. I have been able to generate the key without a problem. My issue is that processing the req on an uninitialized card with no previous certs it seems that the > openssl pkcs11 engine cannot locate the private key corresponding to the public key previously generated. The output I see from the openssl command is: > > > Did you add the -o option to piv-tool when you generated a keypair? > > Did you set and export the PIV_9*_KEY to point at the output file > created bu piv-tool before you ran the command below? > (* can be A, C, D, E) > > > The reason I ask what you describe would mean your did not set the PIV_9*_KEY > env variable. See comments in pkcs15-piv.c line 810 and 839. > > What would really help is to turn on OpenSC debugging. > In opensc.conf set: > debug = 7; > debug_file = /tmp/opensc-debug.log; > > NOTE: sensitive data such as PINs, will be in the log... > So only send snipits of the log. > > Of interest would be starting with the pkcs15-piv.c:634 ""PIV-II adding objects..." > > Looking for pkcs15-piv.c:727 "No cert found,i=" > :815 "PIV-II adding pub keys...", > :848 "No cert for this pub key i= > :859 "DEE look for env" > > and other pkcs15-piv.c log entries after this. > > > > openssl << EOT > engine dynamic -vvvv -pre SO_PATH:/usr/lib/engines/__engine_pkcs11.so \ > -pre ID:pkcs11 -pre NO_VCHECK:1 \ > -pre LIST_ADD:1 -pre LOAD \ > -pre MODULE_PATH:/usr/lib/opensc-__pkcs11.so > version > req $SSLEAY_CONFIG -engine pkcs11 -md5 -new \ > -key slot_1-id_1 -keyform engine -out ./card3.piva.pem -text > EOT > OpenSSL> (dynamic) Dynamic engine loading support > [Success]: SO_PATH:/usr/lib/engines/__engine_pkcs11.so > [Success]: ID:pkcs11 > [Success]: NO_VCHECK:1 > [Success]: LIST_ADD:1 > [Success]: LOAD > [Success]: MODULE_PATH:/usr/lib/opensc-__pkcs11.so > Loaded: (pkcs11) pkcs11 engine > SO_PATH: Specifies the path to the 'pkcs11-engine' shared library > (input flags): STRING > MODULE_PATH: Specifies the path to the pkcs11 module shared library > (input flags): STRING > PIN: Specifies the pin code > (input flags): STRING > VERBOSE: Print additional details > (input flags): NO_INPUT > QUIET: Remove additional details > (input flags): NO_INPUT > LOAD_CERT_CTRL: Get the certificate from card > (input flags): [Internal] > INIT_ARGS: Specifies additional initialization arguments to the pkcs11 module > (input flags): STRING > OpenSSL> OpenSSL 1.0.1e 11 Feb 2013 > OpenSSL> engine "pkcs11" set. > No keys found. > PKCS11_get_private_key returned NULL > cannot load Private Key from engine > 139902858352296:error:__26096080:engine routines:ENGINE_load_private___key:failed loading private key:eng_pkey.c:126: > unable to load Private Key > error in req > > If I hand craft the cert and load it onto the card, then the pkcs11 engine is able to see the keys, and cert and if I generate a new key and run the openssl command again it succeeds. > > My actual question now is: Is this openssl engine issue something that strikes you as being related to OpenSC or merely that my card is not exposing the private key properly until after the first > initialization? > > Thanks > > Charles Bancroft > Software Engineer > Raytheon BBN Technologies > > > On Wed, May 15, 2013 at 3:35 PM, Douglas E. Engert <dee...@an... <mailto:dee...@an...> <mailto:dee...@an... <mailto:dee...@an...>>> wrote: > > > > On 5/15/2013 12:11 PM, Charlie Bancroft wrote: > > Is there a better technique for generating the first certificate for either the 9A, 9C, 9D or 9E keys than the one described in the wiki? > > Not really. > > The PIV does not store a public key on the card in its own object. > It only stores the public key in a certificate. > > The OpenSC PIV driver emulates a public key object by reading the certificate > and extracting the public key. > > So this is a chicken and egg dilema. > > The response to a keygen is the only time you will get the public key > from the card. The CMS is then expected to save this public key and put it into > certificate request. > > > The pkcs11 openssl engine does not see the private key that I > > generated using piv-tool until after I set the certificate for the first time. > > To get around these problems, when no certificate is found on the card, > the pkcs15-piv.c it will look for the environment variable that points at a file > containing the public key. See the code in pkcs15-piv.c line 851 > "* If we used the piv-tool to generate a key," > The variable is of form PIV_9A_KEY=some file name > The 9A could be 9C, 9D, 9E. > > The PIV tool is setup to save the key when it is generated using the -o option. > > Also see card-piv.c line 661 > /* TODO: -DEE Could add key to cache so could use engine to generate key, > * and sign req in single operation */ > > > I had to fall back to manually crafting the cert with bouncycastle. > > The piv-tool -o option has the file name ending in the keyID > for example -o cards/$1.9A ($1 is a card number) > > In a genreq.sh one could then do: > > KEYID=9A > PIV_9A_KEY=cards/$1.$KEYID > export PIV_9A_KEY > > openssl << EOT > engine dynamic -vvvv -pre SO_PATH:$OPENSC_ENGINE/__engines/engine_pkcs11.so -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:$MODULE > version > req $SSLEAY_CONFIG -engine pkcs11 -keyform engine -sha1 -new -key slot_1-id_$ID -out cards/$1.myreq.$KEYID.pem -text > > EOT > > So the engine would call PKCS#11, and the code in pkjcs15-piv.c would > find no certificarte, then read the name of the public key file > form the env variable PIV_9A_KEY, and present it as a public key object > as it it was on the card. > > > Once I sent down this generated cert the > > pkcs15-tool was able to see the public key, private key and cert properly. Any time after this point I can use the piv-tool to erase and reset the keys/certs without a problem. > > > > Could this just be a result of the cards implementation of PIV? Or is this something related to OpenSC itself do you think? > > The NIST 800-73 specs. No public key object. The pubkey can only be read when > the keypair is generated. (Some card vendors may have a way to read the pubkey, but it > is not in the NIST 800-73.) The Pubkey will reside in certificate after that. > > > > Charles Bancroft > > Software Engineer > > Raytheon BBN Technologies > > > > > > ------------------------------__------------------------------__------------------ > > AlienVault Unified Security Management (USM) platform delivers complete > > security visibility with the essential security capabilities. Easily and > > efficiently configure, manage, and operate all of your security controls > > from a single console and one unified framework. Download a free trial. > > http://p.sf.net/sfu/__alienvault_d2d <http://p.sf.net/sfu/alienvault_d2d> > > > > > > > > _________________________________________________ > > Opensc-devel mailing list > > Opensc-devel@lists.__sourceforge.net <mailto:Ope...@li...> <mailto:Opensc-devel@lists.__sourceforge.net <mailto:Ope...@li...>> > > https://lists.sourceforge.net/__lists/listinfo/opensc-devel <https://lists.sourceforge.net/lists/listinfo/opensc-devel> > > > > -- > > Douglas E. Engert <DEE...@an... <mailto:DEE...@an...> <mailto:DEE...@an... <mailto:DEE...@an...>>> > > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 <tel:%28630%29%20252-5444> <tel:%28630%29%20252-5444> > > > ------------------------------__------------------------------__------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/__alienvault_d2d <http://p.sf.net/sfu/alienvault_d2d> > _________________________________________________ > Opensc-devel mailing list > Opensc-devel@lists.__sourceforge.net <mailto:Ope...@li...> <mailto:Opensc-devel@lists.__sourceforge.net <mailto:Ope...@li...>> > https://lists.sourceforge.net/__lists/listinfo/opensc-devel <https://lists.sourceforge.net/lists/listinfo/opensc-devel> > > > > -- > > Douglas E. Engert <DEE...@an... <mailto:DEE...@an...>> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 <tel:%28630%29%20252-5444> > > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |
From: Charlie B. <cha...@gm...> - 2013-05-17 12:07:58
|
Yes, The incorrect environment variable was indeed the problem! It works like a charm now. How should I go about getting the docs updated? Should I file an issue? Or just update things myself? Thanks again for the help Douglas. Charles Bancroft Software Engineer Raytheon BBN Technologies On Thu, May 16, 2013 at 11:23 AM, Douglas E. Engert <dee...@an...>wrote: > > > On 5/16/2013 9:28 AM, Charlie Bancroft wrote: > >> Hrmm, >> I generated the key with the -o option and I am definitely getting >> properly formed public key responses from the card, but I think I may be >> setting the wrong env variable. >> Let me try again with the PIV_9*_KEY variable set. I was using the >> PIV_9A06_KEY as described in the wiki, and it looks like that information >> may be incorrect. I will let you know how it works. If >> it doesn't work as expected, I will follow up with logging information >> for you as well. >> >> > Yes it looks like a documentation issue! At one time it was the kefref and > type > 9A06 the 9A key of type 06 - RSA 1024. > Iin 0.12 or was it 0.13 it was change to the keyref only as PIV_XX_KEY as > there > can only be one key for each keyref, and there is no way to tell what type > and > size of key it is until the pkcs15-piv.c reads the file. (0.13 supports > RSA and > EC keys as per NIST.) > > > > > Thanks again for the help >> >> Charles Bancroft >> Software Engineer >> Raytheon BBN Technologies >> >> >> On Thu, May 16, 2013 at 10:00 AM, Douglas E. Engert <dee...@an...<mailto: >> dee...@an...>> wrote: >> >> >> >> On 5/15/2013 3:36 PM, Charlie Bancroft wrote: >> >> Hi Douglas, >> I may have mis-stated the question. I have been able to generate >> the key without a problem. My issue is that processing the req on an >> uninitialized card with no previous certs it seems that the >> openssl pkcs11 engine cannot locate the private key corresponding >> to the public key previously generated. The output I see from the openssl >> command is: >> >> >> Did you add the -o option to piv-tool when you generated a keypair? >> >> Did you set and export the PIV_9*_KEY to point at the output file >> created bu piv-tool before you ran the command below? >> (* can be A, C, D, E) >> >> >> The reason I ask what you describe would mean your did not set the >> PIV_9*_KEY >> env variable. See comments in pkcs15-piv.c line 810 and 839. >> >> What would really help is to turn on OpenSC debugging. >> In opensc.conf set: >> debug = 7; >> debug_file = /tmp/opensc-debug.log; >> >> NOTE: sensitive data such as PINs, will be in the log... >> So only send snipits of the log. >> >> Of interest would be starting with the pkcs15-piv.c:634 ""PIV-II >> adding objects..." >> >> Looking for pkcs15-piv.c:727 "No cert found,i=" >> :815 "PIV-II adding pub keys...", >> :848 "No cert for this pub key i= >> :859 "DEE look for env" >> >> and other pkcs15-piv.c log entries after this. >> >> >> >> openssl << EOT >> engine dynamic -vvvv -pre SO_PATH:/usr/lib/engines/__**engine_pkcs11.so >> \ >> >> -pre ID:pkcs11 -pre NO_VCHECK:1 \ >> -pre LIST_ADD:1 -pre LOAD \ >> -pre MODULE_PATH:/usr/lib/opensc-__**pkcs11.so >> >> version >> req $SSLEAY_CONFIG -engine pkcs11 -md5 -new \ >> -key slot_1-id_1 -keyform engine -out ./card3.piva.pem >> -text >> EOT >> OpenSSL> (dynamic) Dynamic engine loading support >> [Success]: SO_PATH:/usr/lib/engines/__**engine_pkcs11.so >> >> [Success]: ID:pkcs11 >> [Success]: NO_VCHECK:1 >> [Success]: LIST_ADD:1 >> [Success]: LOAD >> [Success]: MODULE_PATH:/usr/lib/opensc-__**pkcs11.so >> >> Loaded: (pkcs11) pkcs11 engine >> SO_PATH: Specifies the path to the 'pkcs11-engine' shared >> library >> (input flags): STRING >> MODULE_PATH: Specifies the path to the pkcs11 module >> shared library >> (input flags): STRING >> PIN: Specifies the pin code >> (input flags): STRING >> VERBOSE: Print additional details >> (input flags): NO_INPUT >> QUIET: Remove additional details >> (input flags): NO_INPUT >> LOAD_CERT_CTRL: Get the certificate from card >> (input flags): [Internal] >> INIT_ARGS: Specifies additional initialization arguments >> to the pkcs11 module >> (input flags): STRING >> OpenSSL> OpenSSL 1.0.1e 11 Feb 2013 >> OpenSSL> engine "pkcs11" set. >> No keys found. >> PKCS11_get_private_key returned NULL >> cannot load Private Key from engine >> 139902858352296:error:__**26096080:engine >> routines:ENGINE_load_private__**_key:failed loading private >> key:eng_pkey.c:126: >> >> unable to load Private Key >> error in req >> >> If I hand craft the cert and load it onto the card, then the >> pkcs11 engine is able to see the keys, and cert and if I generate a new key >> and run the openssl command again it succeeds. >> >> My actual question now is: Is this openssl engine issue something >> that strikes you as being related to OpenSC or merely that my card is not >> exposing the private key properly until after the first >> initialization? >> >> Thanks >> >> Charles Bancroft >> Software Engineer >> Raytheon BBN Technologies >> >> >> On Wed, May 15, 2013 at 3:35 PM, Douglas E. Engert < >> dee...@an... <mailto:dee...@an...> <mailto:dee...@an...<mailto: >> dee...@an...>>> wrote: >> >> >> >> On 5/15/2013 12:11 PM, Charlie Bancroft wrote: >> > Is there a better technique for generating the first >> certificate for either the 9A, 9C, 9D or 9E keys than the one described in >> the wiki? >> >> Not really. >> >> The PIV does not store a public key on the card in its own >> object. >> It only stores the public key in a certificate. >> >> The OpenSC PIV driver emulates a public key object by >> reading the certificate >> and extracting the public key. >> >> So this is a chicken and egg dilema. >> >> The response to a keygen is the only time you will get the >> public key >> from the card. The CMS is then expected to save this public >> key and put it into >> certificate request. >> >> > The pkcs11 openssl engine does not see the private key >> that I >> > generated using piv-tool until after I set the >> certificate for the first time. >> >> To get around these problems, when no certificate is found >> on the card, >> the pkcs15-piv.c it will look for the environment variable >> that points at a file >> containing the public key. See the code in pkcs15-piv.c line >> 851 >> "* If we used the piv-tool to generate a key," >> The variable is of form PIV_9A_KEY=some file name >> The 9A could be 9C, 9D, 9E. >> >> The PIV tool is setup to save the key when it is generated >> using the -o option. >> >> Also see card-piv.c line 661 >> /* TODO: -DEE Could add key to cache >> so could use engine to generate key, >> * and sign req in single operation */ >> >> > I had to fall back to manually crafting the cert with >> bouncycastle. >> >> The piv-tool -o option has the file name ending in the keyID >> for example -o cards/$1.9A ($1 is a card number) >> >> In a genreq.sh one could then do: >> >> KEYID=9A >> PIV_9A_KEY=cards/$1.$KEYID >> export PIV_9A_KEY >> >> openssl << EOT >> engine dynamic -vvvv -pre SO_PATH:$OPENSC_ENGINE/__**engines/engine_pkcs11.so >> -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre >> MODULE_PATH:$MODULE >> >> version >> req $SSLEAY_CONFIG -engine pkcs11 -keyform engine -sha1 -new >> -key slot_1-id_$ID -out cards/$1.myreq.$KEYID.pem -text >> >> EOT >> >> So the engine would call PKCS#11, and the code in >> pkjcs15-piv.c would >> find no certificarte, then read the name of the public key >> file >> form the env variable PIV_9A_KEY, and present it as a public >> key object >> as it it was on the card. >> >> > Once I sent down this generated cert the >> > pkcs15-tool was able to see the public key, private key >> and cert properly. Any time after this point I can use the piv-tool to >> erase and reset the keys/certs without a problem. >> > >> > Could this just be a result of the cards implementation >> of PIV? Or is this something related to OpenSC itself do you think? >> >> The NIST 800-73 specs. No public key object. The pubkey can >> only be read when >> the keypair is generated. (Some card vendors may have a way >> to read the pubkey, but it >> is not in the NIST 800-73.) The Pubkey will reside in >> certificate after that. >> > >> > Charles Bancroft >> > Software Engineer >> > Raytheon BBN Technologies >> > >> > >> > ------------------------------** >> __----------------------------**--__------------------ >> >> > AlienVault Unified Security Management (USM) platform >> delivers complete >> > security visibility with the essential security >> capabilities. Easily and >> > efficiently configure, manage, and operate all of your >> security controls >> > from a single console and one unified framework. Download >> a free trial. >> > http://p.sf.net/sfu/__**alienvault_d2d<http://p.sf.net/sfu/__alienvault_d2d>< >> http://p.sf.net/sfu/**alienvault_d2d <http://p.sf.net/sfu/alienvault_d2d> >> > >> > >> > >> > >> > ______________________________**___________________ >> > Opensc-devel mailing list >> > Opensc-devel@lists.__sourcefor**ge.net<http://sourceforge.net><mailto: >> Opensc-devel@lists.**sourceforge.net <Ope...@li...>> >> <mailto:Opensc-devel@lists.__s**ourceforge.net <http://sourceforge.net><mailto: >> Opensc-devel@lists.**sourceforge.net <Ope...@li...> >> >> >> > https://lists.sourceforge.net/** >> __lists/listinfo/opensc-devel<https://lists.sourceforge.net/__lists/listinfo/opensc-devel>< >> https://lists.sourceforge.**net/lists/listinfo/opensc-**devel<https://lists.sourceforge.net/lists/listinfo/opensc-devel> >> > >> > >> >> -- >> >> Douglas E. Engert <DEE...@an... <mailto: >> DEE...@an...> <mailto:DEE...@an... <mailto:DEE...@an...>>> >> >> >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 <tel:%28630%29%20252-5444> >> <tel:%28630%29%20252-5444> >> >> >> ------------------------------** >> __----------------------------**--__------------------ >> >> AlienVault Unified Security Management (USM) platform >> delivers complete >> security visibility with the essential security >> capabilities. Easily and >> efficiently configure, manage, and operate all of your >> security controls >> from a single console and one unified framework. Download a >> free trial. >> http://p.sf.net/sfu/__**alienvault_d2d<http://p.sf.net/sfu/__alienvault_d2d>< >> http://p.sf.net/sfu/**alienvault_d2d <http://p.sf.net/sfu/alienvault_d2d> >> > >> ______________________________**___________________ >> Opensc-devel mailing list >> Opensc-devel@lists.__sourcefor**ge.net <http://sourceforge.net><mailto: >> Opensc-devel@lists.**sourceforge.net <Ope...@li...>> >> <mailto:Opensc-devel@lists.__s**ourceforge.net <http://sourceforge.net><mailto: >> Opensc-devel@lists.**sourceforge.net <Ope...@li...> >> >> >> https://lists.sourceforge.net/**__lists/listinfo/opensc-devel<https://lists.sourceforge.net/__lists/listinfo/opensc-devel>< >> https://lists.sourceforge.**net/lists/listinfo/opensc-**devel<https://lists.sourceforge.net/lists/listinfo/opensc-devel> >> > >> >> >> >> >> -- >> >> Douglas E. Engert <DEE...@an... <mailto:DEE...@an...>> >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 <tel:%28630%29%20252-5444> >> >> >> > -- > > Douglas E. Engert <DEE...@an...> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > |
From: Douglas E. E. <dee...@an...> - 2013-05-21 19:53:50
|
On 5/17/2013 7:07 AM, Charlie Bancroft wrote: > Yes, > The incorrect environment variable was indeed the problem! It works like a charm now. How should I go about getting the docs updated? Should I file an issue? Or just update things myself? > https://www.opensc-project.org/opensc/wiki/PivTool has been updated to use the PIV_*_KEY where * = 9A, 9C, 9D or 9E > Thanks again for the help Douglas. > > Charles Bancroft > Software Engineer > Raytheon BBN Technologies > > > On Thu, May 16, 2013 at 11:23 AM, Douglas E. Engert <dee...@an... <mailto:dee...@an...>> wrote: > > > > On 5/16/2013 9:28 AM, Charlie Bancroft wrote: > > Hrmm, > I generated the key with the -o option and I am definitely getting properly formed public key responses from the card, but I think I may be setting the wrong env variable. > Let me try again with the PIV_9*_KEY variable set. I was using the PIV_9A06_KEY as described in the wiki, and it looks like that information may be incorrect. I will let you know how it > works. If > it doesn't work as expected, I will follow up with logging information for you as well. > > > Yes it looks like a documentation issue! At one time it was the kefref and type > 9A06 the 9A key of type 06 - RSA 1024. > Iin 0.12 or was it 0.13 it was change to the keyref only as PIV_XX_KEY as there > can only be one key for each keyref, and there is no way to tell what type and > size of key it is until the pkcs15-piv.c reads the file. (0.13 supports RSA and > EC keys as per NIST.) > > > > > Thanks again for the help > > Charles Bancroft > Software Engineer > Raytheon BBN Technologies > > > On Thu, May 16, 2013 at 10:00 AM, Douglas E. Engert <dee...@an... <mailto:dee...@an...> <mailto:dee...@an... <mailto:dee...@an...>>> wrote: > > > > On 5/15/2013 3:36 PM, Charlie Bancroft wrote: > > Hi Douglas, > I may have mis-stated the question. I have been able to generate the key without a problem. My issue is that processing the req on an uninitialized card with no previous certs it > seems that the > openssl pkcs11 engine cannot locate the private key corresponding to the public key previously generated. The output I see from the openssl command is: > > > Did you add the -o option to piv-tool when you generated a keypair? > > Did you set and export the PIV_9*_KEY to point at the output file > created bu piv-tool before you ran the command below? > (* can be A, C, D, E) > > > The reason I ask what you describe would mean your did not set the PIV_9*_KEY > env variable. See comments in pkcs15-piv.c line 810 and 839. > > What would really help is to turn on OpenSC debugging. > In opensc.conf set: > debug = 7; > debug_file = /tmp/opensc-debug.log; > > NOTE: sensitive data such as PINs, will be in the log... > So only send snipits of the log. > > Of interest would be starting with the pkcs15-piv.c:634 ""PIV-II adding objects..." > > Looking for pkcs15-piv.c:727 "No cert found,i=" > :815 "PIV-II adding pub keys...", > :848 "No cert for this pub key i= > :859 "DEE look for env" > > and other pkcs15-piv.c log entries after this. > > > > openssl << EOT > engine dynamic -vvvv -pre SO_PATH:/usr/lib/engines/____engine_pkcs11.so \ > > -pre ID:pkcs11 -pre NO_VCHECK:1 \ > -pre LIST_ADD:1 -pre LOAD \ > -pre MODULE_PATH:/usr/lib/opensc-____pkcs11.so > > version > req $SSLEAY_CONFIG -engine pkcs11 -md5 -new \ > -key slot_1-id_1 -keyform engine -out ./card3.piva.pem -text > EOT > OpenSSL> (dynamic) Dynamic engine loading support > [Success]: SO_PATH:/usr/lib/engines/____engine_pkcs11.so > > [Success]: ID:pkcs11 > [Success]: NO_VCHECK:1 > [Success]: LIST_ADD:1 > [Success]: LOAD > [Success]: MODULE_PATH:/usr/lib/opensc-____pkcs11.so > > Loaded: (pkcs11) pkcs11 engine > SO_PATH: Specifies the path to the 'pkcs11-engine' shared library > (input flags): STRING > MODULE_PATH: Specifies the path to the pkcs11 module shared library > (input flags): STRING > PIN: Specifies the pin code > (input flags): STRING > VERBOSE: Print additional details > (input flags): NO_INPUT > QUIET: Remove additional details > (input flags): NO_INPUT > LOAD_CERT_CTRL: Get the certificate from card > (input flags): [Internal] > INIT_ARGS: Specifies additional initialization arguments to the pkcs11 module > (input flags): STRING > OpenSSL> OpenSSL 1.0.1e 11 Feb 2013 > OpenSSL> engine "pkcs11" set. > No keys found. > PKCS11_get_private_key returned NULL > cannot load Private Key from engine > 139902858352296:error:____26096080:engine routines:ENGINE_load_private_____key:failed loading private key:eng_pkey.c:126: > > unable to load Private Key > error in req > > If I hand craft the cert and load it onto the card, then the pkcs11 engine is able to see the keys, and cert and if I generate a new key and run the openssl command again it succeeds. > > My actual question now is: Is this openssl engine issue something that strikes you as being related to OpenSC or merely that my card is not exposing the private key properly until > after the first > initialization? > > Thanks > > Charles Bancroft > Software Engineer > Raytheon BBN Technologies > > > On Wed, May 15, 2013 at 3:35 PM, Douglas E. Engert <dee...@an... <mailto:dee...@an...> <mailto:dee...@an... <mailto:dee...@an...>> <mailto:dee...@an... > <mailto:dee...@an...> <mailto:dee...@an... <mailto:dee...@an...>>>> wrote: > > > > On 5/15/2013 12:11 PM, Charlie Bancroft wrote: > > Is there a better technique for generating the first certificate for either the 9A, 9C, 9D or 9E keys than the one described in the wiki? > > Not really. > > The PIV does not store a public key on the card in its own object. > It only stores the public key in a certificate. > > The OpenSC PIV driver emulates a public key object by reading the certificate > and extracting the public key. > > So this is a chicken and egg dilema. > > The response to a keygen is the only time you will get the public key > from the card. The CMS is then expected to save this public key and put it into > certificate request. > > > The pkcs11 openssl engine does not see the private key that I > > generated using piv-tool until after I set the certificate for the first time. > > To get around these problems, when no certificate is found on the card, > the pkcs15-piv.c it will look for the environment variable that points at a file > containing the public key. See the code in pkcs15-piv.c line 851 > "* If we used the piv-tool to generate a key," > The variable is of form PIV_9A_KEY=some file name > The 9A could be 9C, 9D, 9E. > > The PIV tool is setup to save the key when it is generated using the -o option. > > Also see card-piv.c line 661 > /* TODO: -DEE Could add key to cache so could use engine to generate key, > * and sign req in single operation */ > > > I had to fall back to manually crafting the cert with bouncycastle. > > The piv-tool -o option has the file name ending in the keyID > for example -o cards/$1.9A ($1 is a card number) > > In a genreq.sh one could then do: > > KEYID=9A > PIV_9A_KEY=cards/$1.$KEYID > export PIV_9A_KEY > > openssl << EOT > engine dynamic -vvvv -pre SO_PATH:$OPENSC_ENGINE/____engines/engine_pkcs11.so -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:$MODULE > > version > req $SSLEAY_CONFIG -engine pkcs11 -keyform engine -sha1 -new -key slot_1-id_$ID -out cards/$1.myreq.$KEYID.pem -text > > EOT > > So the engine would call PKCS#11, and the code in pkjcs15-piv.c would > find no certificarte, then read the name of the public key file > form the env variable PIV_9A_KEY, and present it as a public key object > as it it was on the card. > > > Once I sent down this generated cert the > > pkcs15-tool was able to see the public key, private key and cert properly. Any time after this point I can use the piv-tool to erase and reset the keys/certs without a problem. > > > > Could this just be a result of the cards implementation of PIV? Or is this something related to OpenSC itself do you think? > > The NIST 800-73 specs. No public key object. The pubkey can only be read when > the keypair is generated. (Some card vendors may have a way to read the pubkey, but it > is not in the NIST 800-73.) The Pubkey will reside in certificate after that. > > > > Charles Bancroft > > Software Engineer > > Raytheon BBN Technologies > > > > > > ------------------------------____----------------------------__--__------------------ > > > AlienVault Unified Security Management (USM) platform delivers complete > > security visibility with the essential security capabilities. Easily and > > efficiently configure, manage, and operate all of your security controls > > from a single console and one unified framework. Download a free trial. > > http://p.sf.net/sfu/____alienvault_d2d <http://p.sf.net/sfu/__alienvault_d2d> <http://p.sf.net/sfu/__alienvault_d2d <http://p.sf.net/sfu/alienvault_d2d>> > > > > > > > > ___________________________________________________ > > Opensc-devel mailing list > > Opensc-devel@lists.__sourcefor__ge.net <http://sourceforge.net> <mailto:Opensc-devel@lists.__sourceforge.net <mailto:Ope...@li...>> > <mailto:Opensc-devel@lists. <mailto:Opensc-devel@lists.>__s__ourceforge.net <http://sourceforge.net> <mailto:Opensc-devel@lists.__sourceforge.net <mailto:Ope...@li...>>> > > https://lists.sourceforge.net/____lists/listinfo/opensc-devel <https://lists.sourceforge.net/__lists/listinfo/opensc-devel> > <https://lists.sourceforge.__net/lists/listinfo/opensc-__devel <https://lists.sourceforge.net/lists/listinfo/opensc-devel>> > > > > -- > > Douglas E. Engert <DEE...@an... <mailto:DEE...@an...> <mailto:DEE...@an... <mailto:DEE...@an...>> <mailto:DEE...@an... <mailto:DEE...@an...> > <mailto:DEE...@an... <mailto:DEE...@an...>>>> > > > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 <tel:%28630%29%20252-5444> <tel:%28630%29%20252-5444> <tel:%28630%29%20252-5444> > > > ------------------------------____----------------------------__--__------------------ > > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/____alienvault_d2d <http://p.sf.net/sfu/__alienvault_d2d> <http://p.sf.net/sfu/__alienvault_d2d <http://p.sf.net/sfu/alienvault_d2d>> > ___________________________________________________ > Opensc-devel mailing list > Opensc-devel@lists.__sourcefor__ge.net <http://sourceforge.net> <mailto:Opensc-devel@lists.__sourceforge.net <mailto:Ope...@li...>> <mailto:Opensc-devel@lists. > <mailto:Opensc-devel@lists.>__s__ourceforge.net <http://sourceforge.net> <mailto:Opensc-devel@lists.__sourceforge.net <mailto:Ope...@li...>>> > https://lists.sourceforge.net/____lists/listinfo/opensc-devel <https://lists.sourceforge.net/__lists/listinfo/opensc-devel> <https://lists.sourceforge.__net/lists/listinfo/opensc-__devel > <https://lists.sourceforge.net/lists/listinfo/opensc-devel>> > > > > > -- > > Douglas E. Engert <DEE...@an... <mailto:DEE...@an...> <mailto:DEE...@an... <mailto:DEE...@an...>>> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 <tel:%28630%29%20252-5444> <tel:%28630%29%20252-5444> > > > > -- > > Douglas E. Engert <DEE...@an... <mailto:DEE...@an...>> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 <tel:%28630%29%20252-5444> > > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |