[opensc-devel] Status of PINPAD support in OpenSC / libccid
Dear Friends, We ordered several PINPAD readers to offer a reliable and affordable solution for OpenSC authentication. At first, we are only performing testing. We should receive testing readers within the next days. We did not make a choice yet. So far, our questions are: 1) What is OpenSC/libccid current PINPAD support? I have to admit last time I used PINPAD was more than a year ago. 2) What does it mean when a reader claims 'secure messaging'. Does it need to be supported on the smartcard side also? Is it a real standard in CCID? Is it well supported in OpenSC? 3) I still wonder why we should declare PINAD in OpenSC configuration file. Is there an alternative, when libccid would discover PINPAD and OpenSC would automatically using it. Could you tell more of the current way that OpenSC discovers the PINPAD. As usual, there will be free hardware for main hackers. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of PINPAD support in OpenSC / libccid
Le 3 octobre 2011 14:02, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : Dear Friends, Hello, We ordered several PINPAD readers to offer a reliable and affordable solution for OpenSC authentication. At first, we are only performing testing. We should receive testing readers within the next days. We did not make a choice yet. So far, our questions are: 1) What is OpenSC/libccid current PINPAD support? I have to admit last time I used PINPAD was more than a year ago. OpenSC/libccid should work fine with pinpad CCID readers. But I do not guarantee it is bug/issue less :-) Some cards require a feature not supported by all pinpad readers. I don't know if this status is documented somewhere. I found this page: https://www.opensc-project.org/opensc/wiki/PinpadReaders 2) What does it mean when a reader claims 'secure messaging'. Does it need to be supported on the smartcard side also? Is it a real standard in CCID? Is it well supported in OpenSC? I am not sure what you call 'secure messaging'. Can you be more specific? 3) I still wonder why we should declare PINAD in OpenSC configuration file. Is there an alternative, when libccid would discover PINPAD and OpenSC would automatically using it. Could you tell more of the current way that OpenSC discovers the PINPAD. AFAIK pinpad support is ON by default if a pinpad reader is detected. But you can disable pinpad support in OpenSC if you want/need. Some pinpad readers have what they call a firewall. The reader will not allow you to use a VERIFY command without using the pinpad feature i.e. it is not possible to send a PIN 'in the clear' to the card without using the pinpad feature. As usual, there will be free hardware for main hackers. What models do you have? Maybe you have a pinpad reader I do not have myself already. Bye, -- 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] Problems with opensc+openvpn builds from Alon starting v10
Martin, I need your help here... On Fri, Sep 30, 2011 at 8:18 PM, busin...@reebs.org wrote: Here you go: C:\Program Files\OpenVPN\share\openvpn-win32\configpkcs15-tool --list-keys Using reader with a card: O2Micro CCID SC Reader 0 Private RSA Key [Private Key] Object Flags : [0x3], private, modifiable Usage : [0x4], sign Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref : 0 (0x0) Native : yes Path : 3f0050154b0130450012 Auth ID : 01 ID : 45 C:\Program Files\OpenVPN\share\openvpn-win32\configpkcs15-tool --list-certificates Using reader with a card: O2Micro CCID SC Reader 0 X.509 Certificate [Certificate] Object Flags : [0x2], modifiable Authority : no Path : 3f0050154545 ID : 45 Encoded serial : 02 01 02 C:\Program Files\OpenVPN\share\openvpn-win32\config On Fri, 30 Sep 2011 18:45:31 +0300, Alon Bar-Lev alon.bar...@gmail.com wrote: --- 2011-09-30 12:05:15.330 [opensc-pkcs11] iso7816.c:103:iso7816_check_sw: Command incompatible with file structure 2011-09-30 12:05:15.330 [opensc-pkcs11] card-flex.c:1067:cryptoflex_compute_signature: Card returned error: -1200 (Card command failed) 2011-09-30 12:05:15.330 [opensc-pkcs11] sec.c:56:sc_compute_signature: returning with: -1200 (Card command failed) 2011-09-30 12:05:15.330 [opensc-pkcs11] card.c:330:sc_unlock: called 2011-09-30 12:05:15.330 [opensc-pkcs11] pkcs15-sec.c:380:sc_pkcs15_compute_signature: sc_compute_signature() failed: -1200 (Card command failed) 2011-09-30 12:05:15.330 [opensc-pkcs11] card.c:330:sc_unlock: called 2011-09-30 12:05:15.330 [opensc-pkcs11] reader-pcsc.c:548:pcsc_unlock: called 2011-09-30 12:05:15.330 [opensc-pkcs11] framework-pkcs15.c:2721:pkcs15_prkey_sign: Sign complete. Result -1200. 2011-09-30 12:05:15.330 [opensc-pkcs11] misc.c:59:sc_to_cryptoki_error_common: libopensc return value: -1200 (Card command failed) 2011-09-30 12:05:15.330 [opensc-pkcs11] pkcs11-object.c:635:C_Sign: C_Sign() = CKR_GENERAL_ERROR --- What I also need is dump of the card content. Paste the output of pkcs15-tool --list-keys pkcs15-tool --list-certificates On Fri, Sep 30, 2011 at 1:16 PM, busin...@reebs.org wrote: Here is the log with verb 255 and the associated OpenVPN log verb 255. Rgrds On Thu, 29 Sep 2011 22:42:35 +0300, Alon Bar-Lev alon.bar...@gmail.com wrote: It should be opensc.conf somewhere that is pointed by registry. See the installation script. On Thu, Sep 29, 2011 at 10:34 PM, busin...@reebs.org wrote: Ok I will do this, however how would I enable this log using the Builds you provided?! Strange is also that while the first attempt, it asks twice for the PIN, for the second and following connection attempts (I aborded here not to loose start of log because of buffer limitations) it asks only once... On Thu, 29 Sep 2011 21:13:52 +0300, Alon Bar-Lev alon.bar...@gmail.com wrote: This is strange. The signature just fails I need opensc logs. It returns CKR_GENERAL_ERROR when tries to sign. On Thu, Sep 29, 2011 at 12:25 PM, busin...@reebs.org wrote: So finally I managed to get the log. For some reasons today it worked from command line allthough it did not in GUI. Probably some delay caused by management interface which is interferring with OpenVPN when log ammount is high... Anyway here is the file _(had to paste it from command prompt), hope that helps! On Thu, 29 Sep 2011 11:00:57 +0300, Alon Bar-Lev alon.bar...@gmail.com wrote: Well, I need log to be able to help. If th ui canno handle this, try without ui. This UI uses the management interface in order to provide the passphrase at port 11196. You can telnet this port and see management-notes.txt of how to work with it. Or.. To open a bug within the ui so it be able to enable more logging. On Wed, Sep 28, 2011 at 7:01 PM, busin...@reebs.org wrote: This does not work. If I set Verb above 7 I get following loop under Command Line and GUI: http://imageshack.us/photo/my-images/829/unbenanntrg.jpg/ until it fails. If I set log filename.txt in the configuration file and run from CLI, it will go up to the point where pin is required but then fail as it cannot get pin from stdin (btw using win32 version on win Xp and card is former Cryptoflex from gemalto): On Wed, 28 Sep 2011 18:30:14 +0300, Alon Bar-Lev alon.bar...@gmail.com wrote: set verb 255 and log to a file. On Wed, Sep 28, 2011 at 5:10 PM, busin...@reebs.org wrote: Yes now download works!!! However still not able to connect. I tried both command line and GUI. Same issue: 1- After it ask for PIN and I enter PIN it immediately asks for the PIN again 2- It then tries to connect, but nothing happens 3- After 60 seconde it times out 4- Start another connection attempt
Re: [opensc-devel] C_login() with CKU_SO user type with Athena Asepcos card
Hello William, Le 30/09/2011 15:42, HOURY William a écrit : I have noticed a strange behavior when trying to unblock the user PIN using PKCS#11 on a Athena ASEPCOS card configured with 2 PIN 2PUK as follow : PKCS#15 Card [OpenSC Card]: Version : 0 Serial number : 0106535458140F10 Manufacturer ID: OpenSC Project Last update : 20110727143948Z Flags : EID compliant PIN [Security Officer PIN] Object Flags : [0x3], private, modifiable ID : ff Flags : [0x92], local, initialized, soPin Length : min_len:4, max_len:16, stored_len:8 Pad char : 0x00 Reference : 2 Type : ascii-numeric Path : 3f005015 PIN [] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x12], local, initialized Length : min_len:4, max_len:16, stored_len:8 Pad char : 0x00 Reference : 4 Type : ascii-numeric Path : 3f005015 Using PKCS#11, if I perform a C_Login() with the CKU_SO user type, I must enter the Security officer PIN if I want the operation to succeed. Afaik, for the Athena ASEPCOS card the SoPIN and UserPUK are different codes, and so you should not use CKU_SO login to unlock User PIN. (PUK code have no associated PKCS#15 authentication object). You can use the 'C_SetPIN in unlogged session' mode of the unblock procedure. For this you have to set 'user_pin_unblock_style = set_pin_in_unlogged_session' in the pkcs#11 section of your opensc.conf. With this setting the following 'works-for-me': #./build/bin/pkcs11-tool --module ./build/lib/opensc-pkcs11.so --slot 1 --unlock-pin --puk Please enter the new PIN: Please enter the new PIN again: PIN successfully changed Normally you should be able to use CKU_CONTEXT_SPECIFIC login type, but actually something is rotten in it's implementation -- will see it later. It would make more sense to enter the user PUK since the main goal of this operation is to be able to unblock the user PIN code… Thanks William Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of PINPAD support in OpenSC / libccid
Hello, On 10/3/11 3:02 , Jean-Michel Pouré - GOOZE wrote: 1) What is OpenSC/libccid current PINPAD support? I have to admit last time I used PINPAD was more than a year ago. What exactly is your question? The support for pinpads has been there for several years for now. As noted in code, it often requires vendor specific hacks as many readers are bogus (they only support a subset of what is defined in CCID, for example restricted min/max PIN lengths or entry conditions). 2) What does it mean when a reader claims 'secure messaging'. Does it need to be supported on the smartcard side also? Is it a real standard in CCID? Is it well supported in OpenSC? I assume you refer to authenticated communication between terminal (firmware) and card? This would require support on card as well as in terminal. This would be quite closely coupled and does not really relate to OpenSC. 3) I still wonder why we should declare PINAD in OpenSC configuration file. Is there an alternative, when libccid would discover PINPAD and OpenSC would automatically using it. Could you tell more of the current way that OpenSC discovers the PINPAD. This is exactly how it is working. There is an option in opensc.conf to turn the pinpad *off* (as it is enabled by default) if there are problems with the device or some application. Note that pinpad support in applications and platform libraries (OS X, Windows) varies. -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of PINPAD support in OpenSC / libccid
Hello, On Mon, Oct 3, 2011 at 16:07, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Some pinpad readers have what they call a firewall. The reader will not allow you to use a VERIFY command without using the pinpad feature i.e. it is not possible to send a PIN 'in the clear' to the card without using the pinpad feature. This should be quite limited list and is AFAIK not more than a few models at the moment. Maybe adding a note to the nice reader list would be useful, for readers which are publicly available and known to contain this feature? Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of PINPAD support in OpenSC / libccid
2011/10/3 Martin Paljak mar...@martinpaljak.net: Hello, On Mon, Oct 3, 2011 at 16:07, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Some pinpad readers have what they call a firewall. The reader will not allow you to use a VERIFY command without using the pinpad feature i.e. it is not possible to send a PIN 'in the clear' to the card without using the pinpad feature. This should be quite limited list and is AFAIK not more than a few models at the moment. Maybe adding a note to the nice reader list would be useful, for readers which are publicly available and known to contain this feature? Martin, do you have such a list? The only one I know is the Gemalto pinpad reader new version. And I think the firewall feature can be enabled or not depending on the reader (hardware) configuration. Bye -- 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] Status of PINPAD support in OpenSC / libccid
Le lundi 03 octobre 2011 à 15:07 +0200, Ludovic Rousseau a écrit : What models do you have? Maybe you have a pinpad reader I do not have myself already. Thanks Ludovic and Martin. We ordered several PINPAD for testing and we can't tell more at the moment. We'll get back to you later on. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.12.3 master plan
Hello Douglas, Le 09/09/2011 17:13, Viktor Tarasov a écrit : Le 09/09/2011 17:05, Douglas E. Engert a écrit : On 9/9/2011 3:07 AM, Viktor Tarasov wrote: Le 09/09/2011 09:38, Martin Paljak a écrit : Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] I don't think it is different signatures, its that our code changes some of the same routines, and defines a structure. We need to use the same structure. I will try to merge your 'ECDH' into my 'SM' one, and so we'll see how big is the difference. It seems that 'algo_refs' member of pkcsk15_skey_info data is not used. Will you keep it for the future usage? https://github.com/dengert/OpenSC/blob/ecdh/src/libopensc/pkcs15.h#L413 The merge is painless, do you consider your ECDH branch as more or less finished? I will merge it into my SM branch. - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. Coverity scan: https://github.com/viktorTarasov/OpenSC/tree/coverity-scanhttps://github.com/viktorTarasov/OpenSC/commits/coverity-scan [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging For secure messaging it's rather: https://github.com/viktorTarasov/OpenSC/tree/secure-messaginghttps://github.com/viktorTarasov/OpenSC/commits/secure-messaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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 mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.12.3 master plan
On 10/3/2011 12:50 PM, Viktor Tarasov wrote: Hello Douglas, Le 09/09/2011 17:13, Viktor Tarasov a écrit : Le 09/09/2011 17:05, Douglas E. Engert a écrit : On 9/9/2011 3:07 AM, Viktor Tarasov wrote: Le 09/09/2011 09:38, Martin Paljak a écrit : Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] I don't think it is different signatures, its that our code changes some of the same routines, and defines a structure. We need to use the same structure. I will try to merge your 'ECDH' into my 'SM' one, and so we'll see how big is the difference. It seems that 'algo_refs' member of pkcsk15_skey_info data is not used. Will you keep it for the future usage? https://github.com/dengert/OpenSC/blob/ecdh/src/libopensc/pkcs15.h#L413 Sure. The merge is painless, do you consider your ECDH branch as more or less finished? I will merge it into my SM branch. Yes. The main issue remaining was compiling without OPENSSL, as the USE_PKCS15_INIT would test for OPENSSL and delete a lot of code needed to create PKCS$11 session objects. Although the ECDH and C_DeriveKey does did not depend on OPENSSL, it did depend on much of the USE_PKCS15_INIT code. Martin said: IMHO the following assumptions should be applied: - USE_PKCS15_INIT should disappear altogether So that was the last major issue I had. - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. Coverity scan: https://github.com/viktorTarasov/OpenSC/tree/coverity-scanhttps://github.com/viktorTarasov/OpenSC/commits/coverity-scan [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging For secure messaging it's rather: https://github.com/viktorTarasov/OpenSC/tree/secure-messaginghttps://github.com/viktorTarasov/OpenSC/commits/secure-messaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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 -- 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
Re: [opensc-devel] Status of PINPAD support in OpenSC / libccid
Hi! Some pinpad readers have what they call a firewall. The reader will not allow you to use a VERIFY command without using the pinpad feature i.e. it is not possible to send a PIN 'in the clear' to the card without using the pinpad feature. This should be quite limited list and is AFAIK not more than a few models at the moment. Maybe adding a note to the nice reader list would be useful, for readers which are publicly available and known to contain this feature? Martin, do you have such a list? The only one I know is the Gemalto pinpad reader new version. And I think the firewall feature can be enabled or not depending on the reader (hardware) configuration. You can add Reiner SCT's cyberJack RFID komfort and cyberJack RFID standard to this list (both also support SM, which is absolutely transparent to the application). I have been told that filtering VERIFY (or similar commands) is bound to a certain type of card. Cheers, Frank. pgpXNaGSvU3BS.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
