Re: [opensc-devel] Proposed cardmod patch
"Douglas E. Engert" a écrit sur 20/01/2011 00:46:51 : > [image supprimée] > > Proposed cardmod patch > > Douglas E. Engert > > A : > > OpenSC-devel > > 20/01/2011 00:49 > > Cc : > > Brian Thomas, François Leblanc > > Attached is a patch to the cardmod code to do the following: > > (1) Fix an uninitialized stricture by by using calloc > in stead of malloc. With out this it was having problems > with checking the status on the reader. > > (2) Implement a change that this should work for Brian Thomas > that allows one to not detect the reader when creating > the sc_context. This uses the > SC_CONTEXT_PARAM_DONT_DETECT_READERS flag in the ctx_params > > (The more I think about this, this should be the default > to not detect the readers during the sc_create_ctx, as > a flag on opensc.conf could control this instead.) > >(2) Eliminate the storing of the SCARDCONTEXT and SCARDHANDLE > in the registry. Instead, cardmod.c will store them > in its VENDOR_SCPECIFIC structure, call sc_context_create > with the SC_CONTEXT_PARAM_DONT_DETECT_READERS flag set > in the ctx_params. It will then modify the ctx, > and then call sc_ctx_detect_readers that will call the > cardmod code in reader-pcsc.c that will use the SCARDCONTEXT > and SCARDHANDLE. > > I can get this to work in Vista with certutil -SCinfo, but there > is some issue as is says it can not open the key. I think this > is an issue with using a 39 character key container name and a > constant for a serial number. > Probably it's why I need help on how exactly work a minidriver, the cardmod base is to let us test it and must be improve... > It does not work with login or runas. This may be the same issue > with after reading the certificate, it is not registering the > container so it can be used later. > > The patch is against 0.12.0. and was built on Ubuntu. > > I would hope Brian and François could look this over to see if it > should be committed. > > It's close to the first release I've develop see the start http://www.opensc-project.org/pipermail/opensc-devel/2009-October/012610.html but Martin at this time was not hot to introduce such extra configuration on context params structure. Martin provide another links to patch introducing solution using key register... We discuss about another way to do that and finally I choice one, this not perfect but at least it let us have something to start and see if mini driver can working with opensc. So it doesn't mind for me the way passing smartcard context and handle to pcsc, if you prefer this way it's ok but I think we lose time since this can be change/ improve after successfully develop a complete minidriver functionnal (with windows login...) > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > [pièce jointe "cardmod.20110119.patch.txt" supprimée par Francois > LEBLANC/CEV/FR/GCD] If I introduce key register to limit witch programs can use cardmod is not a mistake but a functionnality, saying that it's not correct it's a nonsense after we can discuss about the utility of such functionnality... Concerning the patch, you provide adresses of pcsc context and handle in the structure VENDOR_SPECIFIC module opensc-cardmod32.dll to pcsc reader in module libopensc.dll, I'm not sure that such adresses can be provided betwen dll??? Regards, François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
Hello, On Jan 20, 2011, at 1:46 AM, Douglas E. Engert wrote: > Attached is a patch to the cardmod code to do the following: > > (1) Fix an uninitialized stricture by by using calloc >in stead of malloc. With out this it was having problems >with checking the status on the reader. malloc->calloc is always good. > (2) Implement a change that this should work for Brian Thomas >that allows one to not detect the reader when creating >the sc_context. This uses the >SC_CONTEXT_PARAM_DONT_DETECT_READERS flag in the ctx_params > >(The more I think about this, this should be the default >to not detect the readers during the sc_create_ctx, as >a flag on opensc.conf could control this instead.) I think the approach of not auto-detecting readers on context creation is better approach than the flag. At the same time I don't see any other reasons NOT to detect readers, only when initializing the pcsc driver (and I mean pcsc-driver, not the copy in reader-pcsc.c) with the pre-existing handles. Also, reducing one to a single context creation function (sc_establish_context wrapper vs sc_context_create) would do good. > (2) Eliminate the storing of the SCARDCONTEXT and SCARDHANDLE >in the registry. Instead, cardmod.c will store them >in its VENDOR_SCPECIFIC structure, call sc_context_create >with the SC_CONTEXT_PARAM_DONT_DETECT_READERS flag set >in the ctx_params. It will then modify the ctx, >and then call sc_ctx_detect_readers that will call the >cardmod code in reader-pcsc.c that will use the SCARDCONTEXT >and SCARDHANDLE. Using non-windows names (pcsc_context, pcsc_card_handle) would be better than phchmTypeName. Other than that, it looks good, I'll do the mentioned changes in a sec. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
Hello, sorry for the question out of the subject, but When using OpenSC minidriver (or any other), does there any existing (or that could be implemented) possibility to re-actualize the card content and to propagate the eventual changes to the Windows key stores without re-inserting the card? I imagine something like: - card is used for windows logon and authentication (for ex. in IE); - the on-card certificate is renewed/imported with some third application that accesses directly the card; Is it possible to make these changes available for the Windows applications without card re-insertion ? On 20.01.2011 00:46, Douglas E. Engert wrote: > Attached is a patch to the cardmod code to do the following: > > (1) Fix an uninitialized stricture by by using calloc > in stead of malloc. With out this it was having problems > with checking the status on the reader. > > (2) Implement a change that this should work for Brian Thomas > that allows one to not detect the reader when creating > the sc_context. This uses the > SC_CONTEXT_PARAM_DONT_DETECT_READERS flag in the ctx_params > > (The more I think about this, this should be the default > to not detect the readers during the sc_create_ctx, as > a flag on opensc.conf could control this instead.) > > (2) Eliminate the storing of the SCARDCONTEXT and SCARDHANDLE > in the registry. Instead, cardmod.c will store them > in its VENDOR_SCPECIFIC structure, call sc_context_create > with the SC_CONTEXT_PARAM_DONT_DETECT_READERS flag set > in the ctx_params. It will then modify the ctx, > and then call sc_ctx_detect_readers that will call the > cardmod code in reader-pcsc.c that will use the SCARDCONTEXT > and SCARDHANDLE. > > I can get this to work in Vista with certutil -SCinfo, but there > is some issue as is says it can not open the key. I think this > is an issue with using a 39 character key container name and a > constant for a serial number. > > It does not work with login or runas. This may be the same issue > with after reading the certificate, it is not registering the > container so it can be used later. > > The patch is against 0.12.0. and was built on Ubuntu. > > I would hope Brian and François could look this over to see if it > should be committed. > > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
Hello, On Jan 20, 2011, at 11:28 AM, francois.lebl...@cev-sa.com wrote: > "Douglas E. Engert" a écrit sur 20/01/2011 00:46:51 : > > It's close to the first release I've develop see the start > > http://www.opensc-project.org/pipermail/opensc-devel/2009-October/012610.html > > but Martin at this time was not hot to introduce such extra configuration > on Sorry, I don't know what "extra configuration" you are talking about.. > context params structure. Martin provide another links to patch > introducing > > solution using key register... I provided a link to an alternative solution (using environment variables and proper modifications for PC/SC driver to behave accordingly, not copying of the code) with the hope of encouraging you to investigate your solution and think about possible alternative approaches. Using registry to pass function parameters is weird to say the least, maintaining copypaste code (like the cardmod driver) instead of creating proper conditional behavior (in the PC/SC driver, which it is by nature) is a bad luck wish for developers and maintainers. Yes, using context creation parameters is the solution that I had in mind, which fits into OpenSC as needed. > If I introduce key register to limit witch programs can use cardmod is not > > a mistake but a functionnality, saying that it's not correct it's a > nonsense > > after we can discuss about the utility of such functionnality... > > > > Concerning the patch, > > you provide adresses of pcsc context and handle in the structure > VENDOR_SPECIFIC > > module opensc-cardmod32.dll to pcsc reader in module libopensc.dll, I'm > not sure > > that such adresses can be provided betwen dll??? They are both LONG-s, why couldn't they be passed between DLL-s? -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
Martin Paljak a écrit sur 20/01/2011 13:40:02 : > [image supprimée] > > Re: [opensc-devel] Proposed cardmod patch > > Martin Paljak > > A : > > francois.leblanc > > 20/01/2011 13:42 > > Cc : > > "Douglas E. Engert", OpenSC-devel, Brian Thomas > > Hello, > > On Jan 20, 2011, at 11:28 AM, francois.lebl...@cev-sa.com wrote: > > "Douglas E. Engert" a écrit sur 20/01/2011 00:46:51 : > > > > It's close to the first release I've develop see the start > > > > http://www.opensc-project.org/pipermail/opensc-devel/2009-October/ > 012610.html > > > > but Martin at this time was not hot to introduce such extra configuration > > on > Sorry, I don't know what "extra configuration" you are talking about.. It's bad translation of what I want to say, I talk about pcsc context and handle in parameters structure. As far as remember you discouraged to introduce too much modification in opensc code (and It's ok for me) and to limit the impact the prefered way to transmit this parameters are to use variables environment or key register. > > > context params structure. Martin provide another links to patch > > introducing > > > > solution using key register... > > I provided a link to an alternative solution (using environment > variables and proper modifications for PC/SC driver to behave > accordingly, not copying of the code) with the hope of encouraging > you to investigate your solution and think about possible > alternative approaches. Yes but remember, I've started to introduce parameters in structure to pass pcsc handle and context and when I proposed the patch you provide the link you told about using environment variables, so I guess if you provide this link it's because you prefer other way than structure parameters? Now you seem more agree to have this solution? After I describe the three possibility that we can use, params in structure, environment variable, key registers... Each solution is not perfect but I made a choice at this time using one. if you're ok now to add parameters in structure to pass pcsc context and handle like I've said at this time and now It's ok for me. The main goal is to have something working. > > Using registry to pass function parameters is weird to say the > least, maintaining copypaste code (like the cardmod driver) instead > of creating proper conditional behavior (in the PC/SC driver, which > it is by nature) is a bad luck wish for developers and maintainers. > > Yes, using context creation parameters is the solution that I had in > mind, which fits into OpenSC as needed. > > > If I introduce key register to limit witch programs can use cardmod is not > > > > a mistake but a functionnality, saying that it's not correct it's a > > nonsense > > > > after we can discuss about the utility of such functionnality... > > > > > > > > Concerning the patch, > > > > you provide adresses of pcsc context and handle in the structure > > VENDOR_SPECIFIC > > > > module opensc-cardmod32.dll to pcsc reader in module libopensc.dll, I'm > > not sure > > > > that such adresses can be provided betwen dll??? > > They are both LONG-s, why couldn't they be passed between DLL-s? Oh, sure adresses can be passed, but does addressed value can be correctly retreive? It's a question for my own curiosity about memory management under windows... > > -- > @MartinPaljak.net > +3725156495 > regards, François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
On 1/20/2011 3:43 AM, Martin Paljak wrote: > Hello, > > On Jan 20, 2011, at 1:46 AM, Douglas E. Engert wrote: > >> Attached is a patch to the cardmod code to do the following: >> >> (1) Fix an uninitialized stricture by by using calloc >> in stead of malloc. With out this it was having problems >> with checking the status on the reader. > malloc->calloc is always good. > > >> (2) Implement a change that this should work for Brian Thomas >> that allows one to not detect the reader when creating >> the sc_context. This uses the >> SC_CONTEXT_PARAM_DONT_DETECT_READERS flag in the ctx_params >> >> (The more I think about this, this should be the default >> to not detect the readers during the sc_create_ctx, as >> a flag on opensc.conf could control this instead.) > > I think the approach of not auto-detecting readers on context creation is > better approach than the flag. At the same time I don't see any other reasons > NOT to detect readers, only when initializing the pcsc driver (and I mean > pcsc-driver, not the copy in reader-pcsc.c) with the pre-existing handles. > > Also, reducing one to a single context creation function > (sc_establish_context wrapper vs sc_context_create) would do good. > The problem was how to pass in the pcsc_context and pcsc_card_handle provided by the BaseCSP to the cardmod code in reader_pcsc without using the Registry. The ctx_params is only used by the sc_context_create. Yes some better way to do this would be good. Brian Thomas has not yet responded. I would like to here if any of the above approachs would work for him. All he has said was to bypass the call at L622, but never said how he gets the BaseCSP provided handles into OpenSC. Also he was targeting XP. This needs to work on Vista and W7 too. > >> (2) Eliminate the storing of the SCARDCONTEXT and SCARDHANDLE >> in the registry. Instead, cardmod.c will store them >> in its VENDOR_SCPECIFIC structure, call sc_context_create >> with the SC_CONTEXT_PARAM_DONT_DETECT_READERS flag set >> in the ctx_params. It will then modify the ctx, >> and then call sc_ctx_detect_readers that will call the >> cardmod code in reader-pcsc.c that will use the SCARDCONTEXT >> and SCARDHANDLE. > > Using non-windows names (pcsc_context, pcsc_card_handle) would be better than > phchmTypeName. No problem, I just used the same names provided by Microsoft. > > Other than that, it looks good, I'll do the mentioned changes in a sec. Good. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
On 1/20/2011 4:53 AM, Viktor TARASOV wrote: > Hello, > > sorry for the question out of the subject, but > > When using OpenSC minidriver (or any other), > does there any existing (or that could be implemented) > possibility to re-actualize the card content and to propagate the > eventual changes to the Windows key stores > without re-inserting the card? That is be a function of the higher level code in Windows, and should be present. http://technet.microsoft.com/en-us/library/ff404300(WS.10).aspx Windows uses a container name derived from the serial number, and the keyid, (and maybe the type of card), and stored these in the certificate store. The current cardmod driver is using a constant serial number, 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 which will work for a single smartcard, but needs to be fixed to use the card's serial number. It is also using an index starting a 0 for the cert id. See below. From my previous CSP experiences, during login, the cert from the card is obtained, and used without having to be in the registry. It will be added in by login. The command: certutil -user -v -store My or to look at a specific cert, add the cert number to the command certutil -user -v -store My 17 can be used to look at your own certificates in the registry. If a cert is associated with a smart card you will be asked to insert the card, and prompted for a PIN. If the wrong card is inserted you wil be asked again. I have PIV cards that can be used on Windows 7 using the Microsoft driver. I can also use the same PIV card on Vista with the OpenSC cardmod driver, and compare the differences. The card serial number shows up the same, as it is derived from the PIV CHUID object that, that has a GUID in it. It looks like Microsoft and Opensc are doing the same thing. I need to check some more on this. The output on Windows 7 (with vim line numbers shown): 1 My 2 Certificate 17 3 X509 Certificate: 4 Version: 3 5 Serial Number: 1507cdb4000feb0d 136 CERT_MD5_HASH_PROP_ID(4): 137 b2 e0 24 ce 78 9c 67 70 ab 31 2c 7a 4c e5 01 76 138 139 Unknown Property(91): 140 06 00 00 00 00 00 00 00 05 00 00 00 02 00 00 00 141 10 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 142 00 00 00 00 143 144 CERT_KEY_IDENTIFIER_PROP_ID(20): 145 56 75 70 c1 d7 9d 32 d0 18 8e f1 e0 4a 09 76 d7 a4 b2 78 e2 146 147 CERT_SHA1_HASH_PROP_ID(3): 148 ce 9d df aa 6a 75 b5 67 7e ec e1 a7 9c 16 a8 f4 0b 9b 68 09 149 150 CERT_KEY_PROV_INFO_PROP_ID(2): 151 Key Container = c97a8e6b-d21d-b211-b719-00144f5fc105 152 Provider = Microsoft Base Smart Card Crypto Provider 153 ProviderType = 1 154 Flags = 0 155 KeySpec = 1 -- AT_KEYEXCHANGE (On Vista with cardmod, the above shows up as AT_SIGNATURE) This my be why login does not work! 156 157 Unknown Property(90): 158 01 00 00 00 159 Smart Card Serial Number: 6b 8e 7a c9 1d d2 11 b2 b7 19 00 14 4f 1f 5e f4 160 PP_KEYSTORAGE = 1 161 CRYPT_SEC_DESCR -- 1 162 KP_PERMISSIONS = 0 172 Private key is NOT exportable 173 Encryption test passed 174 CertUtil: -store command completed successfully. Line (159) matches what is shown by OpenSC as serial number. Line (151) is the key Container number, and it looks like it is based on the serial number if treated as a GUID. But with bytes swapped, to little endian: c97a8e6b <-> c9 7a 8e 6b d21d <-> 1d d2 b211 <-> 11 b2 b719 <-> 19 b7 00144f == 00 14 4f 5fc105 != 1f 5e f4 But for the cert, the 5fc105 is from the NIST 800-73-3 part 1 table 2 as the PIV BER-TLV Tag. So Microsoft has combined part of the serial number and the tag to create a container. (It may not be unique as the last part of the GUID has been droped!) > > I imagine something like: > - card is used for windows logon and authentication (for ex. in IE); > - the on-card certificate is renewed/imported with some third application > that accesses directly the card; > Is it possible to make these changes available for the Windows applications > without card re-insertion ? I believe it is already there in the BaseCSP. Its just the cardmod driver has some bugs in the area of returning the correct response to find a specific certificate. P.S. Thanks for the question, having looked closer at the certutil -user -v -store My command I am off to try a patch for AT_KEYEXCHANGE with login! > > > On 20.01.2011 00:46, Douglas E. Engert wrote: >> Attached is a patch to the cardmod code to do the following: >> >> (1) Fix an uninitialized stricture by by using calloc >> in stead of malloc. With out this it was having problems >> with checking the status on the reader. >> >> (2) Implement a change that this should work for Brian Thomas >> that allows one to not detect the reader when creating >> the sc_context. This uses the >> SC_CONTEXT_
Re: [opensc-devel] Proposed cardmod patch
> Windows uses a container name derived from the serial number, > and the keyid, (and maybe the type of card), and stored these in the > certificate store. > The current cardmod driver is using a constant serial number, > 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 which will work for a single > smartcard, but needs to be fixed to use the card's serial number. Thanks. This is major information. What do you think? -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
Thank you very much for this answer. On 20.01.2011 17:51, Douglas E. Engert wrote: > On 1/20/2011 4:53 AM, Viktor TARASOV wrote: >> Hello, >> >> sorry for the question out of the subject, but >> >> When using OpenSC minidriver (or any other), >> does there any existing (or that could be implemented) >> possibility to re-actualize the card content and to propagate the >> eventual changes to the Windows key stores >> without re-inserting the card? > That is be a function of the higher level code in Windows, and > should be present. > > http://technet.microsoft.com/en-us/library/ff404300(WS.10).aspx > > Windows uses a container name derived from the serial number, > and the keyid, (and maybe the type of card), and stored these in the > certificate store. > > The current cardmod driver is using a constant serial number, > 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 which will work for a single > smartcard, but needs to be fixed to use the card's serial number. > It is also using an index starting a 0 for the cert id. > See below. > > From my previous CSP experiences, during login, the cert from the card > is obtained, and used without having to be in the registry. It will > be added in by login. > > The command: > certutil -user -v -store My > > or to look at a specific cert, add the cert number to the command > certutil -user -v -store My 17 > > can be used to look at your own certificates in the registry. > If a cert is associated with a smart card you will be asked to insert > the card, and prompted for a PIN. If the wrong card is inserted you wil > be asked again. > > I have PIV cards that can be used on Windows 7 using the Microsoft driver. > I can also use the same PIV card on Vista with the OpenSC cardmod driver, > and compare the differences. > > The card serial number shows up the same, as it is derived from > the PIV CHUID object that, that has a GUID in it. It looks like Microsoft > and Opensc are doing the same thing. I need to check some more on this. > > The output on Windows 7 (with vim line numbers shown): > 1 My > 2 Certificate 17 > 3 X509 Certificate: > 4 Version: 3 > 5 Serial Number: 1507cdb4000feb0d > > 136 CERT_MD5_HASH_PROP_ID(4): > 137 b2 e0 24 ce 78 9c 67 70 ab 31 2c 7a 4c e5 01 76 > 138 > 139 Unknown Property(91): > 140 06 00 00 00 00 00 00 00 05 00 00 00 02 00 00 00 > 141 10 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 > 142 00 00 00 00 > 143 > 144 CERT_KEY_IDENTIFIER_PROP_ID(20): > 145 56 75 70 c1 d7 9d 32 d0 18 8e f1 e0 4a 09 76 d7 a4 b2 78 e2 > 146 > 147 CERT_SHA1_HASH_PROP_ID(3): > 148 ce 9d df aa 6a 75 b5 67 7e ec e1 a7 9c 16 a8 f4 0b 9b 68 09 > 149 > 150 CERT_KEY_PROV_INFO_PROP_ID(2): > 151 Key Container = c97a8e6b-d21d-b211-b719-00144f5fc105 > 152 Provider = Microsoft Base Smart Card Crypto Provider > 153 ProviderType = 1 > 154 Flags = 0 > 155 KeySpec = 1 -- AT_KEYEXCHANGE > > (On Vista with cardmod, the above shows up as AT_SIGNATURE) > This my be why login does not work! > > > 156 > 157 Unknown Property(90): > 158 01 00 00 00 > 159 Smart Card Serial Number: 6b 8e 7a c9 1d d2 11 b2 b7 19 00 14 4f 1f 5e f4 > 160 PP_KEYSTORAGE = 1 > 161 CRYPT_SEC_DESCR -- 1 > 162 KP_PERMISSIONS = 0 > > 172 Private key is NOT exportable > 173 Encryption test passed > 174 CertUtil: -store command completed successfully. > > Line (159) matches what is shown by OpenSC as serial number. > Line (151) is the key Container number, and it looks like it is > based on the serial number if treated as a GUID. But with bytes swapped, > to little endian: > c97a8e6b<-> c9 7a 8e 6b > d21d<-> 1d d2 > b211<-> 11 b2 > b719<-> 19 b7 > 00144f == 00 14 4f > 5fc105 != 1f 5e f4 > > But for the cert, the 5fc105 is from the NIST 800-73-3 part 1 table 2 > as the PIV BER-TLV Tag. > So Microsoft has combined part of the serial number and the tag > to create a container. (It may not be unique as the last part of the > GUID has been droped!) > >> I imagine something like: >> - card is used for windows logon and authentication (for ex. in IE); >> - the on-card certificate is renewed/imported with some third application >> that accesses directly the card; >> Is it possible to make these changes available for the Windows applications >> without card re-insertion ? > I believe it is already there in the BaseCSP. Its just the cardmod driver > has some bugs in the area of returning the correct response to find a > specific certificate. > > > P.S. Thanks for the question, having looked closer at the >certutil -user -v -store My > command I am off to try a patch for AT_KEYEXCHANGE with login! Thank you very much for the details. Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www
Re: [opensc-devel] Misleading information about capabilities of readers
Hello "Aventra", I did not get any reply to my mail. Does the patch works for you? Thanks 2011/1/13 Ludovic Rousseau : > 2011/1/13 Aventra : >> Hi, >> >> Sorry, a typo when doing logging... >> Attached is a new log. > > Found the bug (I think). > > The CCID driver calculate a timeout accordings to the card ATR. In > your case the timeout is 1428 ms rounded to 2 seconds. > Log says: > 0007 ifdhandler.c:791:IFDHSetProtocolParameters() Timeout: 2 seconds > > The same timeout is used by the reader and by the CCID driver. I think > the CCID driver (libusb in fact) triggers its timeout just before the > reader does. So the driver do not get the reader error message. > > Patch to try: > in src/ifdhandler.c edit the function T1_card_timeout() (at the end of the > file) > and replace > return timeout; > by > return timeout+1; > > Then regenerate a log again. > > Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
Hello, We have confirmed this patch works for us. Good job! Question: what would it take to get this patch committed to trunk and released officially? Perhaps an OpenSC version 12.01? We are in dire need of this. Thanks, Brian Thomas -Original Message- From: Douglas E. Engert [mailto:deeng...@anl.gov] Sent: Wednesday, January 19, 2011 5:47 PM To: OpenSC-devel Cc: Brian Thomas; François Leblanc Subject: Proposed cardmod patch Attached is a patch to the cardmod code to do the following: (1) Fix an uninitialized stricture by by using calloc in stead of malloc. With out this it was having problems with checking the status on the reader. (2) Implement a change that this should work for Brian Thomas that allows one to not detect the reader when creating the sc_context. This uses the SC_CONTEXT_PARAM_DONT_DETECT_READERS flag in the ctx_params (The more I think about this, this should be the default to not detect the readers during the sc_create_ctx, as a flag on opensc.conf could control this instead.) (2) Eliminate the storing of the SCARDCONTEXT and SCARDHANDLE in the registry. Instead, cardmod.c will store them in its VENDOR_SCPECIFIC structure, call sc_context_create with the SC_CONTEXT_PARAM_DONT_DETECT_READERS flag set in the ctx_params. It will then modify the ctx, and then call sc_ctx_detect_readers that will call the cardmod code in reader-pcsc.c that will use the SCARDCONTEXT and SCARDHANDLE. I can get this to work in Vista with certutil -SCinfo, but there is some issue as is says it can not open the key. I think this is an issue with using a 39 character key container name and a constant for a serial number. It does not work with login or runas. This may be the same issue with after reading the certificate, it is not registering the container so it can be used later. The patch is against 0.12.0. and was built on Ubuntu. I would hope Brian and François could look this over to see if it should be committed. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
On 1/20/2011 11:32 AM, Jean-Michel Pouré - GOOZE wrote: > >> Windows uses a container name derived from the serial number, >> and the keyid, (and maybe the type of card), and stored these in the >> certificate store. >> The current cardmod driver is using a constant serial number, >> 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 which will work for a single >> smartcard, but needs to be fixed to use the card's serial number. > > Thanks. This is major information. > > What do you think? I have gotten further today. The current cardmod code does provide a AT_KEYEXCHANGE type key and has not implemented the CardRSADecrypt function. So I duplicated the code in CardGetContainerInfo to return both a CALG_RSA_SIGN and a CALG_RSA_KEYX. This may not be correct, as the keyUsage should be used to set if the prkey can be used to sign and/or decrypt. But I got further: "runas" will now prompt for the PIN but then gets an error but does not flush the logs to it is not clear how it got. certutil -SCinfo will read the card an prompt for the PIN. It will pop up a window to show the certificate, and one of the options is to install the certificate in the cert store. But it also tries to test the key. The log is closed properly, and shows that the CardRSADecrypt is missing. There is still some issues with finding the key. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
Brian, You still have not told us how you mini driver loads any of the OpenSC code. Does it use any of the cardmod code? I ask because the patch you need may be only part of what I proposed basicaly (2). I would like to ask Martin, as he had comments on the patch. On 1/20/2011 3:00 PM, Brian Thomas wrote: > Hello, > > We have confirmed this patch works for us. Good job! Question: what would it > take to get this patch committed to trunk and released officially? Perhaps > an OpenSC version 12.01? We are in dire need of this. > > Thanks, > Brian Thomas > > -Original Message- > From: Douglas E. Engert [mailto:deeng...@anl.gov] > Sent: Wednesday, January 19, 2011 5:47 PM > To: OpenSC-devel > Cc: Brian Thomas; François Leblanc > Subject: Proposed cardmod patch > > Attached is a patch to the cardmod code to do the following: > > (1) Fix an uninitialized stricture by by using calloc > in stead of malloc. With out this it was having problems > with checking the status on the reader. > > (2) Implement a change that this should work for Brian Thomas > that allows one to not detect the reader when creating > the sc_context. This uses the > SC_CONTEXT_PARAM_DONT_DETECT_READERS flag in the ctx_params > > (The more I think about this, this should be the default > to not detect the readers during the sc_create_ctx, as > a flag on opensc.conf could control this instead.) > > (3) Eliminate the storing of the SCARDCONTEXT and SCARDHANDLE > in the registry. Instead, cardmod.c will store them > in its VENDOR_SCPECIFIC structure, call sc_context_create > with the SC_CONTEXT_PARAM_DONT_DETECT_READERS flag set > in the ctx_params. It will then modify the ctx, > and then call sc_ctx_detect_readers that will call the > cardmod code in reader-pcsc.c that will use the SCARDCONTEXT > and SCARDHANDLE. > > I can get this to work in Vista with certutil -SCinfo, but there is some > issue as is says it can not open the key. I think this is an issue with using > a 39 character key container name and a constant for a serial number. > > It does not work with login or runas. This may be the same issue with after > reading the certificate, it is not registering the container so it can be > used later. > > The patch is against 0.12.0. and was built on Ubuntu. > > I would hope Brian and François could look this over to see if it should be > committed. > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Proposed cardmod patch
Le jeudi 20 janvier 2011 à 15:44 -0600, Douglas E. Engert a écrit : > I have gotten further today. Dear Douglas, You may look at MySmartLogon source code: http://www.mysmartlogon.com/products/eidauthenticate.html If the certs are valid, smartcard logon can be enabled. This tool can be used to check certificates. You may read source code and contact the authors who knows very well Windows logon issues. But I guess this is mainly a container issue as you explained. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Braking change in OpenSC 0.12.0 tokenInfo
Hi,
Could this fix that Andre has proposed be committed to trunk?
It should work for all cards, since it only makes two elements of the TokenInfo
optional.
Kind regards,
Toni
> -Original Message-
> From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
> Sent: 10. tammikuuta 2011 16:24
> To: Aventra development
> Cc: opensc-devel@lists.opensc-project.org
> Subject: Re: [opensc-devel] Braking change in OpenSC 0.12.0 tokenInfo
>
> This patch should fix it:
>
> Index: libopensc/pkcs15.c
> ===
> --- libopensc/pkcs15.c(revision 5078)
> +++ libopensc/pkcs15.c(working copy)
> @@ -42,8 +42,8 @@
> { "algorithmPKCS#11", SC_ASN1_INTEGER,SC_ASN1_TAG_INTEGER,
> 0, NULL, NULL },
> { "parameters", SC_ASN1_NULL, SC_ASN1_TAG_NULL,
> 0,
> NULL, NULL },
> { "supportedOperations",SC_ASN1_BIT_FIELD, SC_ASN1_TAG_BIT_STRING,
> 0, NULL, NULL },
> - { "objId", SC_ASN1_OBJECT, SC_ASN1_TAG_OBJECT,
> 0,
> NULL, NULL },
> - { "algRef", SC_ASN1_INTEGER,SC_ASN1_TAG_INTEGER,
> 0,
> NULL, NULL },
> + { "objId", SC_ASN1_OBJECT, SC_ASN1_TAG_OBJECT,
> SC_ASN1_OPTIONAL, NULL, NULL },
> + { "algRef", SC_ASN1_INTEGER,SC_ASN1_TAG_INTEGER,
> SC_ASN1_OPTIONAL, NULL, NULL },
> { NULL, 0, 0, 0, NULL, NULL }
> };
>
> On Mon, 2011-01-10 at 11:21 +0200, Aventra development wrote:
> > Hi,
> >
> >
> >
> > I have been testing the new release and sadly found a braking change
> > that causes cards that are not initialized with (the current version
> > of) OpenSC to result in the message “Unsupported card”. The cause is
> > the token info (5032 file). There is some element that OpenSC
> > requires, otherwise it results in “Unsupported Card”.
> >
> >
> >
> > Previously OpenSC worked well with cards not initialized with it, but
> > now it seems that it does not. Does anybody know what changed and why?
> >
> > I tried to browse the source and the changes, but did not manage to
> > track it back to any change that affected this… I’m not even sure when
> > this change has been done, but somewhere between versions 0.11.13 and
> > 0.12.0.
> >
> >
> >
> > Any help would be appreciated. Below is a log that shows the error and
> > the content of the tokenInfo file. The major difference is that cards
> > not initialized by OpenSC does not have the lastUpdate value.
> >
> >
> >
> > Debug log and below that there is a more detailed log about ASN.1
> > parsing:
> >
> >
> >
> > 2011-01-05 12:26:07.066 [pkcs15-tool] card.c:548:sc_select_file:
> > called; type=2, path=3f0050155032
> >
> > 2011-01-05 12:26:07.066 [pkcs15-tool]
> > card-myeid.c:202:myeid_select_file: called
> >
> >
> >
> > 2011-01-05 12:26:07.066 [pkcs15-tool] apdu.c:527:sc_transmit_apdu:
> > called
> >
> > 2011-01-05 12:26:07.066 [pkcs15-tool] card.c:295:sc_lock: called
> >
> > 2011-01-05 12:26:07.081 [pkcs15-tool] reader-pcsc.c:242:pcsc_transmit:
> > reader 'O2 O2Micro CCID SC Reader 0'
> >
> > 2011-01-05 12:26:07.081 [pkcs15-tool] apdu.c:187:sc_apdu_log:
> >
> > Outgoing APDU data [ 10 bytes] =
> >
> > 00 A4 08 00 04 50 15 50 32 FF .P.P2.
> >
> > ==
> >
> > 2011-01-05 12:26:07.081 [pkcs15-tool]
> > reader-pcsc.c:175:pcsc_internal_transmit: called
> >
> > 2011-01-05 12:26:07.175 [pkcs15-tool] apdu.c:187:sc_apdu_log:
> >
> > Incoming APDU data [ 27 bytes] =
> >
> > 6F 17 80 02 00 46 82 01 01 83 02 50 32 86 03 03 oF.P2...
> >
> > 3F FF 85 02 00 00 8A 01 07 90 00?..
> >
> > ==
> >
> > 2011-01-05 12:26:07.175 [pkcs15-tool] card.c:329:sc_unlock: called
> >
> > 2011-01-05 12:26:07.175 [pkcs15-tool]
> > card-myeid.c:240:myeid_process_fci: called
> >
> >
> >
> > 2011-01-05 12:26:07.191 [pkcs15-tool]
> > iso7816.c:304:iso7816_process_fci: processing FCI bytes
> >
> > 2011-01-05 12:26:07.191 [pkcs15-tool]
> > iso7816.c:309:iso7816_process_fci: file identifier: 0x5032
> >
> > 2011-01-05 12:26:07.191 [pkcs15-tool]
> > iso7816.c:316:iso7816_process_fci: bytes in file: 70
> >
> > 2011-01-05 12:26:07.191 [pkcs15-tool]
> > iso7816.c:335:iso7816_process_fci: shareable: no
> >
> > 2011-01-05 12:26:07.191 [pkcs15-tool]
> > iso7816.c:355:iso7816_process_fci: type: working EF
> >
> > 2011-01-05 12:26:07.206 [pkcs15-tool]
> > iso7816.c:357:iso7816_process_fci: EF structure: 1
> >
> > 2011-01-05 12:26:07.206 [pkcs15-tool]
> > card-myeid.c:256:myeid_process_fci: id (5032) sec_attr (3 3F FF)
> >
> > 2011-01-05 12:26:07.206 [pkcs15-tool]
> > card-myeid.c:269:myeid_process_fci: File id (5032) status
> > SC_FILE_STATUS_ACTIVATED (0x7)
> >
> > 2011-01-05 12:26:07.222 [pkcs15-tool]
> >
