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: Markus K. <ko...@rr...> - 2013-05-23 12:34:14
|
On 05/17/2013 04:03 PM, Jean-Michel Pouré - GOOZE wrote: > Please refer to: > http://www.gooze.eu/howto/smartcard-quickstarter-guide/recommendations Using (full install including the mini driver) 32bit OpenSC 0.13 on Windows 7 x86 and the following registry entries --------- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\FTCOS-PK-01C] "80000001"="opensc-minidriver.dll" "ATR"=hex:3b,9f,95,81,31,fe,9f,00,65,46,53,05,30,06,71,df,00,00,00,80,6a,82,5e "ATRMask"=hex:FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,00,FF,FF,FF,FF,FF,FF,00,00,00,00 "Crypto Provider"="Microsoft Base Smart Card Crypto Provider" "Smart Card Key Storage Provider"="Microsoft Smart Card Key Storage Provider" --------- I grabbed the ATR&mask from the entersafe driver in OpenSC. I have the same problem as you reported here: http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/12439 SCardGetCardTypeProviderName: The system cannot find the file specified. 0x2 (WIN32: 2) The thread does not provide a solution to the problem though. I did not modify the inf file - I just installed OpenSC, added the registry entries, and expected things to work. MfG Markus Kötter |
|
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 |
|
From: Jean-Michel P. - G. <jm...@go...> - 2013-05-17 14:03:29
|
Le vendredi 17 mai 2013 à 10:34 +0200, Markus Kötter a écrit : > I do use OpenSC to initialize and write certificates - but the > Feitian > CSP does not work reading OpenSC written cards for me (in case the > key > is not generated on the card). Please refer to: http://www.gooze.eu/howto/smartcard-quickstarter-guide/recommendations * If you are running only Windows, it is recommended to install Feitian proprietary drivers. Do not use with OpenSC. * If you are using several systems, including GNU/Linux and Windows, you must install OpenSC open source drivers on all platforms. Do not install Feitian tools. In other words, you cannot mix drivers. If you are planning to use OpenSC, you should also initialize the card with OpenSC. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu |
|
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: Johannes B. <Joh...@hr...> - 2013-05-17 09:48:56
|
Am Montag 06 Mai 2013 schrieb Martin Paljak <ma...@ma...>: > > As said before: do have a peek at the log of an actual verification > performed by Firefox. Firefox, pkcs11-tool and pkcs15-tool work with the card. They send the pin with lenth 10, padded with FF (see below). It is only opensc-explorer, that doesn't pass the pin with length 10 I guess now I have to learn how to write the certificat to the card using pkcs11-tool I tested with opensc 0.12.2 Johannes ----- 0x7f05005d3700 10:11:20.803 [opensc-pkcs11] apdu.c:184:sc_apdu_log: Outgoing APDU data [ 15 bytes] ===================================== 00 20 00 81 0A 30 34 35 32 39 31 FF FF FF FF . ...045291.... ====================================================================== 0x7f05005d3700 10:11:20.803 [opensc-pkcs11] reader-pcsc.c:176:pcsc_internal_transmit: called 0x7f05005d3700 10:11:20.856 [opensc-pkcs11] apdu.c:184:sc_apdu_log: Incoming APDU data [ 2 bytes] ===================================== 90 00 .. ====================================================================== 0x7f05005d3700 10:11:20.856 [opensc-pkcs11] card.c:330:sc_unlock: called 0x7f05005d3700 10:11:20.856 [opensc-pkcs11] sec.c:204:sc_pin_cmd: returning with: 0 (Success) 0x7f05005d3700 10:11:20.856 [opensc-pkcs11] pkcs15-pin.c:509:sc_pkcs15_pincache_add: called 0x7f05005d3700 10:11:20.856 [opensc-pkcs11] pkcs15-pin.c:543:sc_pkcs15_pincache_add: PIN(User Pin) cached 0x7f05005d3700 10:11:20.856 [opensc-pkcs11] card.c:330:sc_unlock: called 0x7f05005d3700 10:11:20.856 [opensc-pkcs11] reader-pcsc.c:548:pcsc_unlock: called 0x7f05005d3700 10:11:20.861 [opensc-pkcs11] pkcs15-pin.c:296:sc_pkcs15_verify_pin: returning with: 0 (Success) |
|
From: Markus K. <ko...@rr...> - 2013-05-17 08:34:16
|
Hi, On 05/16/2013 02:07 PM, Jean-Michel Pouré - GOOZE wrote: > If you are planning to use the Feitian PKI under Windows and Linux at the same time, > you should only use OpenSC tools to initialize the card and write certificates. > In this case, do not use Feitian tools to initialize the card and write certificates. I do use OpenSC to initialize and write certificates - but the Feitian CSP does not work reading OpenSC written cards for me (in case the key is not generated on the card). The Feitian PKI Manager screenshots attached were just to show the difference in cards written with OpenSC and Feitian tools. I want to write cards with OpenSC, as I'm required to be able to write pkcs12 files as well as generate the key on the card, sign the certificate request and write the certificate to the card. OpenSC makes both easy, I can call pkcs15-tool, and use the openssl pkcs11 engine via m2crypto to sign a csr with a key created on the card. From the docs, I was positive this is supposed to work: * Cards initialized under GNU/Linux are read-only under Windows CAPI/CSP. * Ability to use proprietary drivers in conjunction with OpenSC. > If you are running only Windows, please use Feitian initialization tools, > PKCS11 library and mini-driver. But then don't use OpenSC. I'll have to give the OpenSC mini-driver a shot, just due to the fact there is nobody assisting me in reading OpenSC written cards with the Feitian CSP. > In short, the Feitian smartcard has all needed drivers for Windows and Linux, > but you not mix open-source software (OpenSC) with proprietary software (Feitian). > Make a choice and stick to it. As I said - I was hoping to be able to write with OpenSC on linux and read with Feitian CSP on Windows. The Feitian CSP 'just works' for not OpenSC initialized/written cards, getting the MiniDriver to work is slightly more than just installing OpenSC. > If you are planning to use the card under all systems, you should prefer OpenSC. I will - if I can make it work. MfG Markus Kötter |
|
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-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 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: Jean-Michel P. - G. <jm...@go...> - 2013-05-16 12:32:32
|
Dear Markus,
If you are planning to use the Feitian PKI under Windows and Linux at the same time,
you should only use OpenSC tools to initialize the card and write certificates.
In this case, do not use Feitian tools to initialize the card and write certificates.
If you are running only Windows, please use Feitian initialization tools,
PKCS11 library and mini-driver. But then don't use OpenSC.
In short, the Feitian smartcard has all needed drivers for Windows and Linux,
but you not mix open-source software (OpenSC) with proprietary software (Feitian).
Make a choice and stick to it.
If you are planning to use the card under all systems, you should prefer OpenSC.
Kind regards,
--
Jean-Michel Pouré - Gooze - http://www.gooze.eu
|
|
From: Jean-Michel P. - G. <jm...@go...> - 2013-05-16 12:22:34
|
This is only a test, do not reply.
--
Jean-Michel Pouré - Gooze - http://www.gooze.eu
|
|
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-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: Guest, I. - 1. - M. <ig...@ll...> - 2013-05-15 18:57:56
|
Hello,
I'm trying to use OpenSC Version 0.12.2 on Ubuntu 12.04 32-bit. My
reader and card are both detected and identified correctly when using
pcsc_scan, but when I try to do a "opensc-tool --reader 1 --name" an
"Unsupported Card" message is returned.
A Google search shows that my ATR String (3B DC 18 FF 81 91 FE 1F C3 80
73 C8 21 13 66 01 0B 03 52 00 05 38) appears on git hub in file:
/src/libopensc/card-iasecc.c. Can anyone tell me if this means my card
will be supported in the future? Perhaps it's already supported but I
have a configuration problem? Perhaps it's supported in version 0.13.0?
Any help would be appreciated.
Thanks, Kind regards,
Iestyn Guest
Reader: SCM SCR 331 (P/N 904622)
Card: Athena IDProtect Smart Card Logon Card
pcsc_scan dump:
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau <lud...@fr...>
Compiled with PC/SC lite version: 1.7.4
Using reader plug'n play mechanism
Scanning present readers...
0: Broadcom 5880 [Contacted SmartCard] (0123456789ABCD) 00 00
1: SCM SCR 331 [CCID Interface] (21120939216316) 01 00
Wed May 15 14:15:43 2013
Reader 0: Broadcom 5880 [Contacted SmartCard] (0123456789ABCD) 00 00
Card state: Card removed,
Reader 1: SCM SCR 331 [CCID Interface] (21120939216316) 01 00
Card state: Card inserted, Shared Mode,
ATR: 3B DC 18 FF 81 91 FE 1F C3 80 73 C8 21 13 66 01 0B 03 52 00 05 38
ATR: 3B DC 18 FF 81 91 FE 1F C3 80 73 C8 21 13 66 01 0B 03 52 00 05 38
+ TS = 3B --> Direct Convention
+ T0 = DC, Y(1): 1101, K: 12 (historical bytes)
TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
TC(1) = FF --> Extra guard time: 255 (special value)
TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
-----
TD(2) = 91 --> Y(i+1) = 1001, Protocol T = 1
-----
TA(3) = FE --> IFSC: 254
TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface
bytes following
-----
TA(4) = C3 --> Clock stop: no preference - Class accepted by the
card: (3G) A 5V B 3V
+ Historical bytes: 80 73 C8 21 13 66 01 0B 03 52 00 05
Category indicator byte: 80 (compact TLV data object)
Tag: 7, len: 3 (card capabilities)
Selection methods: C8
- DF selection by full DF name
- DF selection by partial DF name
- Implicit DF selection
Data coding byte: 21
- Behaviour of write functions: proprietary
- Value 'FF' for the first byte of BER-TLV tag fields: invalid
- Data unit in quartets: 2
Command chaining, length fields and logical channels: 13
- Logical channel number assignment: by the card
- Maximum number of logical channels: 4
Tag: 6, len: 6 (pre-issuing data)
Data: 01 0B 03 52 00 05
+ TCK = 38 (correct checksum)
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B DC 18 FF 81 91 FE 1F C3 80 73 C8 21 13 66 01 0B 03 52 00 05 38
Athena IDProtect Smart Card Logon Card
|
|
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: Martin P. <ma...@ma...> - 2013-05-12 07:52:45
|
Hello,
Keep in mind that muscle applet and OpenSC don't match. If you crate
keys the "muscle way" they are not visible to OpenSC, which depends on
virtual objects that get mapped to file system and contain the
necessary directory files. Yet keys created by OpenSC should be usable
though muscle pkcs11.
--
Martin
+372 5156495
On Fri, Apr 19, 2013 at 6:56 PM, Florent Deybach <fde...@gm...> wrote:
> Hello,
>
> I am using a Javacard which is compliant with Java Card 2.2.1 /
> GlobalPlatform 2.1.1
>
> I am using opensc 0.13.0rc1.
>
> I successfully compiled the MuscleApplet 0.9.11 using the JDK 1.4.1 and the
> JavaCard Kit 2.2.1 from Sun.
> The applet was loaded into the card using GPJ and it is usable by
> muscleTool.
> Partially because it seems I cannot generate RSA keys (but that is another
> issue)
> As a proof:
>
>> root@ubuntu12-10:# muscleTool
>> MuscleCard shell - type "help" for help.
>> muscleTool > tokens
>> 1. MuscleCard Applet
>>
>> ListTokens Success.
>> muscleTool > connect 1
>> Connect Success.
>> muscleTool [MuscleCard Applet] > status
>> Protocol Version: 0.1
>> Software Version: 0.6
>> Free Memory: 5998
>> Total Memory: 6000
>> PINs Used: 2
>> Keys Used: 0
>> Logged IDs: NONE
>> GetStatus Successful
>> muscleTool [MuscleCard Applet] >resume
>> Functions Supported
>> -------------------------------
>> MSCGenerateKeys
>> MSCImportKey
>> MSCExportKey
>> MSCComputeCrypt
>> MSCExternalAuthenticate
>> MSCListKeys
>> MSCCreatePIN
>> MSCVerifyPIN
>> MSCChangePIN X
>> MSCUnblockPIN X
>> MSCListPINs
>> MSCCreateObject
>> MSCDeleteObject
>> MSCWriteObject
>> MSCReadObject
>> MSCListObjects
>> MSCLogoutAll X
>> MSCGetChallenge X
>> GetCapabilities Successful
>>
>
> The thing is that I cannot use my card with OpenSC.
> I added the ATR card into the opensc.conf file in order to force the muscle
> driver :
>
>> card_atr 3B:F8:18:00:00:80:31:FE:45:00:73:C8:40:13:00:90:00:92 {
>> driver = muscle;
>>
>> }
>
>
> However opensc tools don't work:
>
>> root@ubuntu12-10# pkcs15-tool -D
>> Using reader with a card: Gemalto USB Shell Token V2 00 00
>> PKCS#15 binding failed: Unsupported card
>
>
>>
>> root@ubuntu12-10:# pkcs15-tool --list-applications
>> Using reader with a card: Gemalto USB Shell Token V2 00 00
>> PKCS#15 binding failed: Unsupported card
>>
>
> The attached debug output shows that no pkcs15 emulator is found (no
> emulator list in config file, trying all builtin emulators)
>
> What is wrong?
> Should I upgrade my opensc installation (I am using the one provided by
> Gooze - http://www.gooze.eu/)?
>
> pkcs11-tool with libmusclepkcs11 seems to be a little more friendly:
>
>> root@ubuntu12-10:# pkcs11-tool --module=/usr/lib/libmusclepkcs11.so.0.0.1
>> -L
>> Available slots:
>> Slot 0 (0x1): Gemalto USB Shell Token V2 00 00
>> token label : MuscleCard Applet
>> token manufacturer : Unknown MFR
>> token model : Unknown Model
>> token flags : rng, login required, PIN initialized, token
>> initialized
>> hardware version : 6.0
>> firmware version : 1.0
>> serial num : 1
>
>
>>
>> root@ubuntu12-10:# pkcs11-tool --module=/usr/lib/libmusclepkcs11.so.0.0.1
>> -M
>> Using slot 0 with a present token (0x1)
>> Supported mechanisms:
>> RSA-PKCS, keySize={96,128}, encrypt, decrypt, sign, sign_recover,
>> verify, verify_recover, wrap, unwrap
>> RSA-PKCS-KEY-PAIR-GEN, keySize={96,128}, generate, generate_key_pair
>> SHA1-RSA-PKCS, encrypt, decrypt, sign, sign_recover, verify,
>> verify_recover, generate, generate_key_pair, wrap, unwrap
>
>
>
> But when it comes to generating keys:
>
>
>> root@ubuntu12-10:# pkcs11-tool --module=/usr/lib/libmusclepkcs11.so.0.0.1
>> -l -k --key-type rsa:2048 -p 00000000 --id 001
>> Using slot 0 with a present token (0x1)
>> Key pair generated:
>> Private Key Object; RSA
>> warning: PKCS11 function C_GetAttributeValue(LABEL) failed: rv =
>> CKR_ATTRIBUTE_TYPE_INVALID (0x12)
>>
>> ID: 4b45593030303030303030303030303030303030
>> Usage: decrypt, sign, unwrap
>> warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed:
>> rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)
>>
>> warning: PKCS11 function C_GetAttributeValue(MODULUS_BITS) failed: rv =
>> CKR_ATTRIBUTE_TYPE_INVALID (0x12)
>>
>> Public Key Object; RSA 0 bits
>> warning: PKCS11 function C_GetAttributeValue(LABEL) failed: rv =
>> CKR_ATTRIBUTE_TYPE_INVALID (0x12)
>>
>> ID: 4b45593030303030303030303030303030303031
>> warning: PKCS11 function C_GetAttributeValue(ENCRYPT) failed: rv =
>> CKR_ATTRIBUTE_TYPE_INVALID (0x12)
>>
>> warning: PKCS11 function C_GetAttributeValue(VERIFY) failed: rv =
>> CKR_ATTRIBUTE_TYPE_INVALID (0x12)
>>
>> warning: PKCS11 function C_GetAttributeValue(WRAP) failed: rv =
>> CKR_ATTRIBUTE_TYPE_INVALID (0x12)
>>
>> Usage: none
>
>
> Thanks is advance
>
> Cheers
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
|
|
From: Martin P. <ma...@ma...> - 2013-05-11 09:47:06
|
Hello, Interesting, especially that you bundle the DLL-s/SO-s with the XPI. For a "generic" solution (lets call it "Firefox PKCS#11 module loader") it: - should have: configurable module path (and name) (with sensible defaults) - must have: loaded with "friendly certs" option by default (keep in mind that this only applies for as long as the slots are available. Thus re-loading the module on every invocation might make sense) Here is some insight: https://svn.eesti.ee/projektid/idkaart_public/branches/3.7.1/esteid-pkcs11-module-loader/chrome/content/pkcs11-loader.js While it makes sense to bundle PKCS#11 module(s) with the XPI, it also makes sense to be able to load the "platform modules" when they exist. I personally gave up with Firefox and use Chrome, which more or less does the right things (except the "friendly certs" thing in NSS) and JustWorks on Mac/Windows. I wish NSS (of Firefox) at some stage would learn to use platform services and cert stores. http://justalilhype.com/blog/alan/files/2011/07/firefox-chrome-internet-explorer-670x480.jpg Martin -- Martin +372 5156495 On Wed, May 8, 2013 at 4:58 PM, Jan Suhr <j1...@su...> wrote: > Hi! > Even though there is already an add-on for Firefox, we now released an > add-on for Firefox and Thunderbird which originates of the Crypto Stick > project. > > Features: > - For Firefox and Thunderbird > - On Windows, Linux, MacOS (for both 32 and 64 bit) > - No prior installation of OpenSC required > - Contains OpenSC 0.13 > > The source code and XPIs are available at: > https://www.assembla.com/code/cryptostick/git-3/nodes > > We would be glad to see it being adopted by the OpenSC project. Anybody > interested? > > Best regards, > Jan > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel |
|
From: Markus K. <ko...@rr...> - 2013-05-10 12:19:17
|
Hi, I'm evaluating Feitian Cards and I've the following problem: When writing the cards with OpenSC - the signed - Feitian Windows driver does not find the private key of the x509 certificate and can't use the certificate therefore (certmgr.msc shows the certificate in the 'other persons -> certificates' tab). Using the card with e.g. Mozilla Firefox with opensc-pkcs11 works fine though. When creating the certificate using a key generated on the card, a card written with opensc works fine too, but we need the possibility to write pkcs12 to the card and use them on Windows. When writing the pkcs12 to card with the Entersafe PKI Manager, the cards work fine on windows too. I noticed the Entersafe PKI Manager has some kind of directory view, which shows the private/public/x509 in the same "directory" in case the card is written with Entersafe PKI Manager - or the keys is generated on the card and the certificate is written with OpenSC. I was unable to figure out how to force a specific 'directory' for the data I need to write. I tried pkcs11-tool to write something, same problem, private key ends up in different "directory" and the (Windows) application (using the Feitian CSP) does not work. I'm using opensc 0.12.2 [gcc 4.6.3] Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) on Ubuntu 12.04 x86_64. Attached is some screenshots of the Entersafe PKI Manager and pkcs15-tool dumps of the cards. entersafe_pki_manager-pkcs12-import - works opensc_pkcs15-tool_key_on_card - works opensc_pkcs15-tool_pkcs12-import - fails I've been working with different usage types already, nothing really matters, it works once the key is in the same directory. How can I enforce the private key to be in the same "directory" as the certificate when writing a pkcs12? MfG Markus Kötter |
|
From: Charlie B. <cha...@gm...> - 2013-05-10 11:54:20
|
After some discussion with Douglas I was able to find a workable solution.
The piece of information I was missing when trying to set all of this up
was the Card Management key. Once I had it, it was a simple matter to
actually unlock the card and get identities loaded onto it.
The first step I had to take was to patch the gpshell program to not crash
and burn when a card comes back as locked. The patch applied is:
Index: gpshell.c
===================================================================
diff --git a/trunk/gpshell/src/gpshell.c b/trunk/gpshell/src/gpshell.c
--- a/trunk/gpshell/src/gpshell.c (revision 419)
+++ b/trunk/gpshell/src/gpshell.c (working copy)
@@ -935,8 +935,13 @@
{
_tprintf (_T("select_application() returns 0x%08lX
(%s)\n"),
status.errorCode, status.errorMessage);
- rv = EXIT_FAILURE;
- goto end;
+
+ /* 6283 is warning we want to continue and
unlock */
+ if (status.errorCode !=
OPGP_ISO7816_WARNING_CM_LOCKED)
+ {
+ rv = EXIT_FAILURE;
+ goto end;
+ }
+ status.errorStatus = OPGP_ERROR_STATUS_SUCCESS;
}
memcpy(selectedAID, optionStr.AID, optionStr.AIDLen);
selectedAIDLength = optionStr.AIDLen;
Once that was compiled and working, the following gpshell script was used
to unlock the card:
mode_211
enable_trace
establish_context
card_connect
select -AID A0000001510000
#Replace the key with your vendors Card Management key.
open_sc -security 1 -keyind 0 -keyver 0 -keyDerivation emvcps11
-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
get_status -element 80
send_apdu -sc 1 -APDU 80F0800F07A0000001510000
card_disconnect
release_context
After running the script, the card is unlocked and you are free to use the
normal OpenSC tools to load data onto the card.
I just wanted to say thanks again to Douglas for all his help. The script
and the patch were contributed by him, with some slight modifications to
make things work for my particular card.
Charles Bancroft
Software Engineer
Raytheon BBN Technologies
On Thu, Apr 11, 2013 at 2:25 PM, Douglas E. Engert <dee...@an...> wrote:
>
>
> On 4/11/2013 12:15 PM, Charlie Bancroft wrote:
> > Hello,
> > I was wondering if there was a way to initialize/personalize an Oberthur
> ID-One PIV (Type A) using opensc?
>
> The intent of the OpenSC modifications was to implement NIST 800-73-3 for
> the client.
> The PIV card is not designed to be updated by a user, and card vendors
> can implement their own card management commands.
>
> The piv-tool was created to allow for testing of cards using what was
> defined
> in NIST 800-73-3. It was not intended to be used as a card management
> system.
> Additional commands may be needed that are vendor specific to finalize
> the card. For example NIST 800-73-3 only defines how to generate a key on
> the
> card. It does not define how to write a key to the.
>
> That said the piv-tool has the -A and -s options that can be used to
> authenticate to the card. The put_cert.sh uses this.
>
> If you have the Oberthur documentation you should have the 9B keys, any
> GlobaPlatform
> keys and additional commands needed to initialize/personalize the cards.
>
> > I have blank (just the PIV applet) cards that I have been fighting with
> trying to initialize
> > to no avail. I have seen that some people have been able to initialize
> the card with piv-tool but I have not seen any detailed instruction as to
> how it was done.
>
> If I recall those Obether ID-ONE cards are based on Globlaplatform 2.1.1.
> NIST insists that the cards be sent with ISD status SECURED and locked.
> Two mods were made to gpshell to not stop on a select with return of
> card locked, and to globalplatform.c to use the different bytes
> of the ISD and keyDerivationData returned from the card. The vendor
> document would indicate the changes needed.
>
> I can send you these mods, but you have to get the keys and documentation
> from
> the vendor.
>
> >
> > Thanks,
> > Charles Bancroft
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Precog is a next-generation analytics platform capable of advanced
> > analytics on semi-structured data. The platform includes APIs for
> building
> > apps and a phenomenal toolset for data science. Developers can use
> > our toolset for easy data analysis & visualization. Get a free account!
> > http://www2.precog.com/precogplatform/slashdotnewsletter
> >
> >
> >
> > _______________________________________________
> > 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
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
|
|
From: Jan S. <j1...@su...> - 2013-05-08 15:02:55
|
Hi! Even though there is already an add-on for Firefox, we now released an add-on for Firefox and Thunderbird which originates of the Crypto Stick project. Features: - For Firefox and Thunderbird - On Windows, Linux, MacOS (for both 32 and 64 bit) - No prior installation of OpenSC required - Contains OpenSC 0.13 The source code and XPIs are available at: https://www.assembla.com/code/cryptostick/git-3/nodes We would be glad to see it being adopted by the OpenSC project. Anybody interested? Best regards, Jan |
|
From: Anthony F. <ant...@gm...> - 2013-05-07 23:49:54
|
Greetings, all -- On Thu, May 2, 2013 at 10:25 AM, Anthony Foiani <ant...@gm...> wrote: > > > On Thu, May 2, 2013 at 10:15 AM, Anthony Foiani > <ant...@gm...> wrote: > > > Or does the private key structure rely on information held in > > the enumeration? > > So apparently it does. > > > If the latter, do we need to somehow provide a way for the key to > > release the entire enumeration when the key itself is freed? I have a solution, but it's very ugly. Please take a look at this branch: https://github.com/tkil/engine_pkcs11/commits/ajf-fixes-201305 It's mostly cleanup patches, but the punchline is in this commit: https://github.com/tkil/engine_pkcs11/commit/91133b719c71d0c92c233a0c29b0d5b94c4ee102 (or: http://preview.tinyurl.com/cdabyyf) The commit message tells the story: Without this patch: ==25864== LEAK SUMMARY: ==25864== definitely lost: 4,920 bytes in 27 blocks ==25864== indirectly lost: 147,092 bytes in 3,137 blocks ==25864== possibly lost: 0 bytes in 0 blocks ==25864== still reachable: 14,231 bytes in 429 blocks ==25864== suppressed: 0 bytes in 0 blocks With this patch: ==25989== LEAK SUMMARY: ==25989== definitely lost: 4,600 bytes in 23 blocks ==25989== indirectly lost: 328 bytes in 5 blocks ==25989== possibly lost: 0 bytes in 0 blocks ==25989== still reachable: 14,231 bytes in 429 blocks ==25989== suppressed: 0 bytes in 0 blocks Note the change in "indirectly lost". The ugly part is that I could not find any way to do it transparently. When we get a key through the OpenSSL engine interface, all we get back is an EVP_PKEY*. I looked, and it doesn't seem that there's any way to add on arbitrary data; even if there were, there's no obvious way for external/third-party programs to modify the set of methods used by a given key. If there were, the right answer would have been: 1. Add the pointer to list of slots, and count of slots, as auxiliary data on the EVP_PKEY; 2. Modify the pkey_free method to free those and then chain to the original. I couldn't find anywhere to stick (1), and (2) was blocked because that method is behind an opaque pointer (the structure itself is defined in the openssl source package under crypto/asn1/asn1_locl.h, but that is not installed into the system headers directory, and it's explicitly mentioned that it's not for external use.) There are ways to get a pointer to the methods, duplicate it, and set a new free function -- but no way to get the original free function (!), so I couldn't chain to the original. Maybe I just missed something. It looks like someone else had a similar idea; in the hw_pcsk11.c file, there was an "#if 0" block with something that tries to chain the rsa_finish method ... but it was obviously not in use. Instead, I modified the engine to keep a separate list of EVP_PKEY* -> slot_list, slot_count mappings, and added an ENGINE_ctrl method to release the slot data given an EVP_PKEY*. I thought that I would still have to free the EVP_PKEY*, but it turns out that freeing the slots frees the keys: PKCS11_release_all_slots calls pkcs11_release_slot, which calls pkcs11_destroy_token, which calls pkcs11_destroy_keys, which calls EVP_PKEY_free This is also the reason that I could not just release the slots before returning the EVP_PKEY* out of engine_pkcs11.c:pkcs11_load_key Anyway. Hopefully others will find this useful. I can submit a proper pull request if you would like. Best regards, Anthony Foiani |
|
From: Martin P. <ma...@ma...> - 2013-05-07 18:33:47
|
There are lots of new warnings that could be detected even with clang or gcc with more warnings. Sent from a device without a proper keyboard. On 5 May 2013 16:58, "Ludovic Rousseau" <lud...@gm...> wrote: > Hi, > > Please find the latest report on new defect(s) introduced to OpenSC > found with Coverity SCAN > > Defect(s) Reported-by: Coverity Scan > Showing 7 of 43 defects > > ** CID 1019105: Destination buffer too small (STRING_OVERFLOW) > > http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10104#mergedDefectId=1019105 > > ** CID 1019104: Wrong sizeof argument (SIZEOF_MISMATCH) > > http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10104#mergedDefectId=1019104 > > ** CID 1019103: Resource leak (RESOURCE_LEAK) > > http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10104#mergedDefectId=1019103 > > ** CID 1019102: Resource leak (RESOURCE_LEAK) > > http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10104#mergedDefectId=1019102 > > ** CID 1019101: Printf arg count mismatch (PW.TOO_MANY_PRINTF_ARGS) > > http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10104#mergedDefectId=1019101 > > ** CID 1019100: Printf arg count mismatch (PW.TOO_MANY_PRINTF_ARGS) > > http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10104#mergedDefectId=1019100 > > ** CID 1019099: Improper use of negative value (NEGATIVE_RETURNS) > > http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10104#mergedDefectId=1019099 > > > These bugs are only the NEW bugs since my last submission (a few > months ago). Many other bugs should also be fixed. > > The URL above can't be used if you do not have an account on coverity. > I would be happy to open an account for you if: > - you are already a developper of OpenSC > - you plan to fix bugs detected by coverity > > Bye > > ________________________________________________________________________ > CID 1019105: Destination buffer too small (STRING_OVERFLOW) > > /src/tools/util.c: 316 ( string_overflow) > 313 sprintf(buf + 3, "#%d", > e->key_ref); > 314 break; > 315 case SC_AC_SCB: > >>> You might overrun the 10 byte destination string "buf" by writing 17 > bytes from ""Sec.ControlByte "". > 316 strcpy(buf, "Sec.ControlByte "); > 317 if (e->key_ref != SC_AC_KEY_REF_NONE) > 318 sprintf(buf + 3, "Ox%X", > e->key_ref); > 319 break; > 320 case SC_AC_IDA: > > > /src/tools/util.c: 321 ( string_overflow) > 318 sprintf(buf + 3, "Ox%X", > e->key_ref); > 319 break; > 320 case SC_AC_IDA: > >>> You might overrun the 10 byte destination string "buf" by writing 16 > bytes from ""PKCS#15 AuthID "". > 321 strcpy(buf, "PKCS#15 AuthID "); > 322 if (e->key_ref != SC_AC_KEY_REF_NONE) > 323 sprintf(buf + 3, "#%d", > e->key_ref); > 324 break; > 325 default: > > ________________________________________________________________________ > CID 1019104: Wrong sizeof argument (SIZEOF_MISMATCH) > > /src/tools/sc-hsm-tool.c: 145 ( suspicious_sizeof) > 142 int bits = 0; > 143 > 144 // Seed the RNG > >>> Passing argument "rngSeed" of type "char *" and argument "8 /* sizeof > (rngSeed) */" to function "RAND_seed" is suspicious. > 145 RAND_seed(rngSeed, sizeof(rngSeed)); > 146 > 147 // Determine minimum number of bits for prime >= max(2^r, > n + 1) > 148 bits = BN_num_bits_word(n + 1) > BN_num_bits(s) ? > (BN_num_bits_word(n + 1)) : (BN_num_bits(s)); > 149 > > ________________________________________________________________________ > CID 1019103: Resource leak (RESOURCE_LEAK) > > /src/tools/sc-hsm-tool.c: 288 ( alloc_fn) > 285 unsigned char j; > 286 > 287 // Array representing the polynomial a(x) = s + a_1 * > x + ... + a_n-1 * x^n-1 mod p > >>> Calling allocation function "malloc". > 288 BIGNUM **bValue = malloc(t * sizeof(BIGNUM *)); > 289 BIGNUM **pbValue; > 290 BIGNUM numerator; > 291 BIGNUM denominator; > 292 BIGNUM temp; > > > /src/tools/sc-hsm-tool.c: 288 ( var_assign) > 285 unsigned char j; > 286 > 287 // Array representing the polynomial a(x) = s + a_1 * > x + ... + a_n-1 * x^n-1 mod p > >>> Assigning: "bValue" = storage returned from "malloc(t * 8UL)". > 288 BIGNUM **bValue = malloc(t * sizeof(BIGNUM *)); > 289 BIGNUM **pbValue; > 290 BIGNUM numerator; > 291 BIGNUM denominator; > 292 BIGNUM temp; > > > /src/tools/sc-hsm-tool.c: 298 ( var_assign) > 295 BN_CTX *ctx; > 296 > 297 // Initialize > >>> Assigning: "pbValue" = "bValue". > 298 pbValue = bValue; > 299 for (i = 0; i < t; i++) { > 300 *pbValue = BN_new(); > 301 BN_init(*pbValue); > 302 pbValue++; > > > /src/tools/sc-hsm-tool.c: 313 ( overwrite_var) > 310 ctx = BN_CTX_new(); > 311 BN_CTX_init(ctx); > 312 > >>> Overwriting "pbValue" in call "pbValue = bValue" leaks the storage > that "pbValue" points to. > 313 pbValue = bValue; > 314 sp_i = shares; > 315 for (i = 0; i < t; i++) { > 316 > 317 BN_one(&numerator); > > > /src/tools/sc-hsm-tool.c: 313 ( var_assign) > 310 ctx = BN_CTX_new(); > 311 BN_CTX_init(ctx); > 312 > >>> Assigning: "pbValue" = "bValue". > 313 pbValue = bValue; > 314 sp_i = shares; > 315 for (i = 0; i < t; i++) { > 316 > 317 BN_one(&numerator); > > > /src/tools/sc-hsm-tool.c: 341 ( leaked_storage) > 338 * multiplication > 339 */ > 340 if (BN_mod_inverse(&denominator, &denominator, > &prime, ctx) == NULL ) { > >>> Variable "bValue" going out of scope leaks the storage it points to. > 341 return -1; > 342 } > 343 > 344 BN_mod_mul(*pbValue, &numerator, &denominator, > &prime, ctx); > 345 > > > /src/tools/sc-hsm-tool.c: 341 ( leaked_storage) > 338 * multiplication > 339 */ > 340 if (BN_mod_inverse(&denominator, &denominator, > &prime, ctx) == NULL ) { > >>> Variable "pbValue" going out of scope leaks the storage it points to. > 341 return -1; > 342 } > 343 > 344 BN_mod_mul(*pbValue, &numerator, &denominator, > &prime, ctx); > 345 > > ________________________________________________________________________ > CID 1019102: Resource leak (RESOURCE_LEAK) > > /src/libopensc/card.c: 70 ( alloc_fn) > 67 struct sc_apdu *apdu = NULL; > 68 > 69 assert(copy_from != NULL); > >>> Calling allocation function "malloc". > 70 apdu = (struct sc_apdu *)malloc(sizeof(struct sc_apdu)); > 71 if (!copy_from || !apdu) > 72 return apdu; > 73 memcpy(apdu, copy_from, sizeof(struct sc_apdu)); > 74 apdu->data = apdu->resp = NULL; > > > /src/libopensc/card.c: 70 ( var_assign) > 67 struct sc_apdu *apdu = NULL; > 68 > 69 assert(copy_from != NULL); > >>> Assigning: "apdu" = storage returned from "malloc(104UL)". > 70 apdu = (struct sc_apdu *)malloc(sizeof(struct sc_apdu)); > 71 if (!copy_from || !apdu) > 72 return apdu; > 73 memcpy(apdu, copy_from, sizeof(struct sc_apdu)); > 74 apdu->data = apdu->resp = NULL; > > > /src/libopensc/card.c: 73 ( noescape) > 70 apdu = (struct sc_apdu *)malloc(sizeof(struct sc_apdu)); > 71 if (!copy_from || !apdu) > 72 return apdu; > >>> Variable "apdu" is not freed or pointed-to in function "memcpy". > 73 memcpy(apdu, copy_from, sizeof(struct sc_apdu)); > 74 apdu->data = apdu->resp = NULL; > 75 apdu->next = NULL; > 76 apdu->datalen = apdu->resplen = 0; > 77 apdu->allocation_flags = SC_APDU_ALLOCATE_FLAG; > > > /src/libopensc/card.c: 82 ( leaked_storage) > 79 if ((flags & SC_APDU_ALLOCATE_FLAG_DATA) && > copy_from->data && copy_from->datalen) { > 80 apdu->data = malloc(copy_from->datalen); > 81 if (!apdu->data) > >>> Variable "apdu" going out of scope leaks the storage it points to. > 82 return NULL; > 83 memcpy(apdu->data, copy_from->data, > copy_from->datalen); > 84 apdu->datalen = copy_from->datalen; > 85 apdu->allocation_flags |= > SC_APDU_ALLOCATE_FLAG_DATA; > 86 } > > > /src/libopensc/card.c: 91 ( leaked_storage) > 88 if ((flags & SC_APDU_ALLOCATE_FLAG_RESP) && > copy_from->resp && copy_from->resplen) { > 89 apdu->resp = malloc(copy_from->resplen); > 90 if (!apdu->resp) > >>> Variable "apdu" going out of scope leaks the storage it points to. > 91 return NULL; > 92 memcpy(apdu->resp, copy_from->resp, > copy_from->resplen); > 93 apdu->resplen = copy_from->resplen; > 94 apdu->allocation_flags |= > SC_APDU_ALLOCATE_FLAG_RESP; > 95 } > > ________________________________________________________________________ > CID 1019101: Printf arg count mismatch (PW.TOO_MANY_PRINTF_ARGS) > > /src/tools/sc-hsm-tool.c: 839 ( too_many_printf_args) > 836 */ > 837 r = sc_get_challenge(card, rngseed, 16); > 838 if (r < 0) { > >>> the format string ends before this argument > 839 printf("Error generating random seed failed > with ", sc_strerror(r)); > 840 OPENSSL_cleanse(pwd, *pwdlen); > 841 free(pwd); > 842 return r; > 843 } > > ________________________________________________________________________ > CID 1019100: Printf arg count mismatch (PW.TOO_MANY_PRINTF_ARGS) > > /src/tools/sc-hsm-tool.c: 816 ( too_many_printf_args) > 813 > 814 r = sc_get_challenge(card, *pwd, 8); > 815 if (r < 0) { > >>> the format string ends before this argument > 816 printf("Error generating random key failed > with ", sc_strerror(r)); > 817 OPENSSL_cleanse(pwd, *pwdlen); > 818 free(pwd); > 819 return r; > 820 } > > ________________________________________________________________________ > CID 1019099: Improper use of negative value (NEGATIVE_RETURNS) > > /src/tools/sc-hsm-tool.c: 1352 ( var_tested_neg) > 1349 int opt_dkek_shares = -1; > 1350 int opt_key_reference = -1; > 1351 int opt_password_shares_threshold = -1; > >>> Assigning: "opt_password_shares_total" = a negative value. > 1352 int opt_password_shares_total = -1; > 1353 int opt_force = 0; > 1354 int opt_iter = 10000000; > 1355 sc_context_param_t ctx_param; > 1356 > > > /src/tools/sc-hsm-tool.c: 1468 ( negative_returns) > 1465 } > 1466 > 1467 if (do_create_dkek_share) { > >>> "opt_password_shares_total" is passed to a parameter that cannot be > negative. > 1468 create_dkek_share(card, opt_filename, > opt_iter, opt_password, opt_password_shares_threshold, > opt_password_shares_total); > 1469 } > 1470 > 1471 if (do_import_dkek_share) { > 1472 import_dkek_share(card, opt_filename, > opt_iter, opt_password, opt_password_shares_total); > > ________________________________________________________________________ > > > > -- > Dr. Ludovic Rousseau > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: Viktor T. <vik...@gm...> - 2013-05-07 14:17:32
|
Le 06/05/2013 16:28, Martin Paljak a écrit : > On Mon, May 6, 2013 at 10:44 AM, Johannes Becker > <Joh...@hr...> wrote: >> OpenSC [3F00/5015]> verify CHV129 30:34:35:32:39:31:FF:FF >> >> Incorrect code. PIN value is invalid. >> OpenSC [3F00/5015]> verify CHV129 30:34:35:32:39:31:FF:FF:FF:FF >> >> Unable to verify PIN code: Invalid arguments PIN length is invalid Probably the PKCS15 AOF descriptor do not correspond to the real format of your PIN (length, padding character, ...??) . Try to pad PIN value with "00" -- at least it's the padding character in the OpenSC profile for CardOS card.:w >> The PIN is accepted when using Firefox. > As said before: do have a peek at the log of an actual verification > performed by Firefox. Best way. |
|
From: Martin P. <ma...@ma...> - 2013-05-06 14:29:25
|
On Mon, May 6, 2013 at 10:44 AM, Johannes Becker <Joh...@hr...> wrote: > OpenSC [3F00/5015]> verify CHV129 30:34:35:32:39:31:FF:FF > > Incorrect code. > > OpenSC [3F00/5015]> verify CHV129 30:34:35:32:39:31:FF:FF:FF:FF > > Unable to verify PIN code: Invalid arguments > The PIN is accepted when using Firefox. As said before: do have a peek at the log of an actual verification performed by Firefox. |
|
From: Florent D. <fde...@gm...> - 2013-05-06 07:56:38
|
Hi Martin, Maybe you can choose a different USB reader. > That again is not an option ;) However you're absolutely right, I tried different USB readers and they work well with virtualBox. The problem is laborious: Launching pcscd when the reader is connected simply kills the virtual machine! By killing I mean the hard way : the window just closes and that's it! No kernel panic, no core dump, no log, nothing! I can simply restart the virtual machine... Anyway, I'll annoy the virtualbox guys :) Thanks again! Cheers |
5 messages has been excluded from this view by a project administrator.
