Re: [opensc-devel] Quick fix
Hello, Both variables should be only filled by pcsc-lite, not read? But you are right - initializing all variables is a good practice. Merged. On Wed, May 18, 2011 at 15:01, Frank Morgner morg...@informatik.hu-berlin.de wrote: Hi! I discovered some errors due to uninitialized parameters. This might only concern opensc when used with pcsc-lite version 1.5.5, but it doesn't hurt to set them anyway. Cheers, Frank. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Coverity scan of OpenSC.
Hello, I added OpenSC to Coverity Scan [1], a closed source static code analyzer (even though it is not visible from the public listing of projects). The initial scan found 434 issues, out of which 134 are about stack size considerations (don't really matter in non-embedded setup IMHO) and the 300 other issues can actually be dealt with (like 23 instances of dead code, 60 secure coding practices (sprintf vs snprintf et al), possible race conditions for accessing files, 76 resource leaks, 9 blocks of code with no effect etc) I now wonder what is the best method of communicating them. To get access to further results (I plan to feed every pre-release like candidate to their checker) an account is needed in their database (AFAIK only Coverity staff can add them). I did not find a way to make reasonable reports as text files, which would show the offending code snippet as well and could be distributed to the list or interested parties. Until I figure out how to distribute the results, please ask me directly for access to the Coverity GUI for inspection. [1] http://scan.coverity.com/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Kobil KAAN Advanced Reader, waiting for card timeout
2011/6/14 Ludovic Rousseau ludovic.rouss...@gmail.com: 2011/6/14 Johannes Becker johannes.bec...@hrz.uni-giessen.de: Am Sonntag 12 Juni 2011 schrieb MAK: Hello, i have the problem that running opensc-tool -w -a gives immediately a timeout if no card is present in the reader. ... I am running opensc-0.12.0, pcsc-lite-1.7.2 and ccid-1.4.4 on a FreeBSD 8.2-RELEASE system. It's the same fault with other readers as well with Debian stable amd64, opensc-0.12.2-svn libpcsclite1 1.5.5-4 libccid 1.4.3-1 On the other hand waiting works on Windows. Also waiting with the perl modules Chipcard::PCSC Chipcard::PCSC::Card works on Linux. It is a bug in OpenSC. Patch attached and also available at [1]. Even if the bug is clearly in OpenSC I also modified pcsc-lite (revision 5795) to avoid the problem with other applications (or older versions of OpenSC). [1] https://github.com/LudovicRousseau/OpenSC/commit/8936901e2b8fade5d9831b224f3313b7b3255133 -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] opensc-tool, verify, Pinpad
Hello, the verify command of opensc-tool promises If key is omitted, card reader's keypad will be used to collect PIN. I doesn't work for me. Is there a way to do it or is this feature not implemented yet? Regards Johannes ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[5567] pkcs11: framework-pkcs15: OpenSC specific ' non-repudiation' cryptoki attribute ...
Hello, On Wed, Jun 15, 2011 at 14:28, Alon Bar-Lev alon.bar...@gmail.com wrote: On Wed, Jun 15, 2011 at 2:05 PM, Martin Paljak mar...@martinpaljak.net wrote: Given that in practice, CKA_ALWAYS_AUTHENTICATE is almost exclusively used with nonrepudiation signature keys and the fact that the usual creation of such keys through PKCS#11 is not a common operation, it sounds like a useful signaling channel. I disagree of the above statement. practice is not related to this. I use my authentication certificate as always authenticate... And I guess people also use this for decryption... It has nothing to do with legal, but for people customization and paranoia. So a much cleaner solution would be to use vendor provided attribute. Yes and no. OpenSC does a lot of translation. It translates non-ISO7816-4-ish commands to generic functions that are expected to behave like ISO7816-X to enable the PKCS#15 support (card drivers). It translates non-PKCS#15 cards into PKCS#15 terms (PKCS#15 emulation code), because that's what is used internally by OpenSC (whether it is the best or most optional abstraction is another question). It translates PKCS#15 into PKCS#11, because that is what applications want. It also translates PKCS#15 to Tokend/CDSA or CryptoAPI. Because there are so many layer in the real life PKI world, it is a nightmare. As always with translation - something gets lost and something gets added by the translator. But the goal of the translator is to be as exact and as close to the original as possible, but adopt the sentence so that it makes sense to the target audience. Like proverbs - you either translate them word by word (like I did) or you use an equivalent which is known to the native speakers of the target language in the given locality. PKCS#11 and CryptoAPI are not just another interfaces, they have different design philosophies and goals. It does not make sense to try to extend the PKCS#15 world to CryptoAPI or implement everything in PKCS#15 layer with only CryptoAPI usage in mind. Rather the best effort to translate in the spirit of target audience should be done (both directions) CKA_ALWAYS_AUTHENTICATE is a property of PKCS#11 which is most similar to userConsent property in PKCS#15. Disregarding the properties, eventually the actual card should behave like advertised. Do all card drivers support (and enforce) authentication before signature feature? I doubt it. Does OpenSC currently allow setting a configured userConsent value when generating keys? Will it be transferred to the card and enforced by the card? AFAIK not (at least not easily). What about userConsent 1? Will we disregard CKA_ALWAYS_AUTHENTICATE, which implies userConsent==1? Yes, some of them are shortcomings in OpenSC (and drivers and cards) and some could be improved (like using userConsent value for PIN cache TTL) and having explicit attributes would be more precise, but it would often only support a low value corner case for maybe a few but maybe zero users. Current CKA_ALWAYS_AUTHENTICATE (and related userConsent==1) relation comes from real life and has proven to be useful. DWIM is a powerful concept ;) You mean admitting that PKCS#11 is limited and making the PKCS#11 personalization mechanism more flexible by endorsing more properties to templates? I don't think it fixes the fundamental issue, that personalization really does not seem to be in the focus of PKCS#11... Right... so either we open libopensc again to allow personalization directly with PKCS#15 as it was before, or we provide some bridge between the two. I don't think that libopensc was actually used (publicly) for personalization. The reason for removing libopensc-dev was to eliminate the I need access to smart cards... google find OpenSC, think 'this is some smart card think, I'll link against it' habit. Up to the point of removing public headers, all users of libopensc should have either used PKCS#11, had already implemented PKCS#11 support or had the code to use libopensc long abandoned/not updated. The main reason of ditching development packages was to draw attention to the fact that libopensc is not the most appropriate interface for adding smart card support to enduser applications. Also, to get rid of the necessity to maintain a kitchen sink API and related ABI issues and focus on published API-s (PKCS#11, Minidriver, Tokend). If there was to become a new application which would focus on card *personalization* through libopensc, would help to sanitize the exported API of libopensc and work with that, it would be most welcome. But I don't know of any such effort or people who would be interested in it. Personalization is often a closed-group hobby or eagerly kept in house. As most enrollment applications are card specific, A good enrollment application should be in control of every aspect of the card. Making sure that every byte on card is in place. So if you have PKCS#15 card, you probably need to create
Re: [opensc-devel] [opensc-commits] svn opensc changed[5567] pkcs11: framework-pkcs15: OpenSC specific ' non-repudiation' cryptoki attribute ...
OK. I think we have all facts. Thanks. On Thu, Jun 16, 2011 at 1:14 PM, Martin Paljak mar...@martinpaljak.net wrote: Hello, On Wed, Jun 15, 2011 at 14:28, Alon Bar-Lev alon.bar...@gmail.com wrote: On Wed, Jun 15, 2011 at 2:05 PM, Martin Paljak mar...@martinpaljak.net wrote: Given that in practice, CKA_ALWAYS_AUTHENTICATE is almost exclusively used with nonrepudiation signature keys and the fact that the usual creation of such keys through PKCS#11 is not a common operation, it sounds like a useful signaling channel. I disagree of the above statement. practice is not related to this. I use my authentication certificate as always authenticate... And I guess people also use this for decryption... It has nothing to do with legal, but for people customization and paranoia. So a much cleaner solution would be to use vendor provided attribute. Yes and no. OpenSC does a lot of translation. It translates non-ISO7816-4-ish commands to generic functions that are expected to behave like ISO7816-X to enable the PKCS#15 support (card drivers). It translates non-PKCS#15 cards into PKCS#15 terms (PKCS#15 emulation code), because that's what is used internally by OpenSC (whether it is the best or most optional abstraction is another question). It translates PKCS#15 into PKCS#11, because that is what applications want. It also translates PKCS#15 to Tokend/CDSA or CryptoAPI. Because there are so many layer in the real life PKI world, it is a nightmare. As always with translation - something gets lost and something gets added by the translator. But the goal of the translator is to be as exact and as close to the original as possible, but adopt the sentence so that it makes sense to the target audience. Like proverbs - you either translate them word by word (like I did) or you use an equivalent which is known to the native speakers of the target language in the given locality. PKCS#11 and CryptoAPI are not just another interfaces, they have different design philosophies and goals. It does not make sense to try to extend the PKCS#15 world to CryptoAPI or implement everything in PKCS#15 layer with only CryptoAPI usage in mind. Rather the best effort to translate in the spirit of target audience should be done (both directions) CKA_ALWAYS_AUTHENTICATE is a property of PKCS#11 which is most similar to userConsent property in PKCS#15. Disregarding the properties, eventually the actual card should behave like advertised. Do all card drivers support (and enforce) authentication before signature feature? I doubt it. Does OpenSC currently allow setting a configured userConsent value when generating keys? Will it be transferred to the card and enforced by the card? AFAIK not (at least not easily). What about userConsent 1? Will we disregard CKA_ALWAYS_AUTHENTICATE, which implies userConsent==1? Yes, some of them are shortcomings in OpenSC (and drivers and cards) and some could be improved (like using userConsent value for PIN cache TTL) and having explicit attributes would be more precise, but it would often only support a low value corner case for maybe a few but maybe zero users. Current CKA_ALWAYS_AUTHENTICATE (and related userConsent==1) relation comes from real life and has proven to be useful. DWIM is a powerful concept ;) You mean admitting that PKCS#11 is limited and making the PKCS#11 personalization mechanism more flexible by endorsing more properties to templates? I don't think it fixes the fundamental issue, that personalization really does not seem to be in the focus of PKCS#11... Right... so either we open libopensc again to allow personalization directly with PKCS#15 as it was before, or we provide some bridge between the two. I don't think that libopensc was actually used (publicly) for personalization. The reason for removing libopensc-dev was to eliminate the I need access to smart cards... google find OpenSC, think 'this is some smart card think, I'll link against it' habit. Up to the point of removing public headers, all users of libopensc should have either used PKCS#11, had already implemented PKCS#11 support or had the code to use libopensc long abandoned/not updated. The main reason of ditching development packages was to draw attention to the fact that libopensc is not the most appropriate interface for adding smart card support to enduser applications. Also, to get rid of the necessity to maintain a kitchen sink API and related ABI issues and focus on published API-s (PKCS#11, Minidriver, Tokend). If there was to become a new application which would focus on card *personalization* through libopensc, would help to sanitize the exported API of libopensc and work with that, it would be most welcome. But I don't know of any such effort or people who would be interested in it. Personalization is often a closed-group hobby or eagerly kept in house. As most enrollment applications are card
Re: [opensc-devel] Do smart card drivers generally support more than one PKCS#11 session?
On 6/15/2011 4:28 PM, Nikos Mavrogiannopoulos wrote: On 06/13/2011 11:11 AM, Stef Walter wrote: On 06/10/2011 07:08 PM, Martin Paljak wrote: On Jun 10, 2011, at 13:11 , Stef Walter wrote: After sleeping on this idea, I realized it won't work in certain cases. In particular when the key has CKA_ALWAYS_AUTHENTICATE and requires C_Login with CKU_CONTEXT_SPECIFIC. This is hardly the case with SSL. CKA_ALWAYS_AUTHENTICATE in OpenSC context for example is only set for keys that require user consent or usually are used for nonrepudiation. Most cards I've seen can use authentication keys once the cardholder is verified until the card is reset or removed. Using such card with a pinpad reader would be impossible for web authentication, you'd be typing the PIN most of the time The card may have two certificate, one that is unlocked once by the browser and one using CKA_ALWAYS_AUTHENTICATE used for signing e-mail. In that the intent of the card issuer forcing CKA_ALWAYS_AUTHENTICATE and setting the policy of using a pin pad reader, is designed to have the user enter the pin. So middle ware developers have to live with policy. Since the PKCS#11 URI's say that the pinfile attribute of the URI can be determined by the application, we can build something simple in p11-kit and register callbacks so that one component (in the same process) can provide the pin for another (like gnutls). I didn't like the pinfile attribute of pkcs11-urls much, because its semantics are undefined. I see it as an option that could cause compatibility issues between libraries using URLs. That's why I have ignored it so far. Are there other alternatives to solve the issue at hand? This might not be answering your direct question, but is relevant to the handling of PINs. One example of using a pin pad reader with a complicated callback mechanism is with login at the console. It involves Gnome or other window manager, PAM, PAM modules like pam_krb5, the Kerberos libs, openssl, openssl_engine, engine_pkcs11 and OpenSC's PKCS11, and pcsc. PAM has conv routines to allow messages, prompting, and input. Kerberos has its own callback routines, as well as the openssl engine ui_method. These can all work together to to pass back a message to the user to use the PIN PAD to enter the pin. This is no input passed back by the callbacks, just the message to the user. Since PAM was designed to start with a user/password, even before determining that a smartcard might be used, the password may be entered as a blank. (It will not be used later.) regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov 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
