Re: [Muscle] SmartCard sign number
On 12/17/2013 7:28 AM, Raul Rosetto Munoz wrote: I'm sure that my card is Safesign, I installed the SafeSign from A.E.T too. But know I have no idea what I can do to sign this number! The problem is not with the smart card, but with understanding what you mean by: I need to sign my device serial number with my smart card, in the documentation that I need to follow just say that I need sign a number like 290953052 and after sign I need to get an data string in base64, followed the PKCS #1 version 1.5. What is: the documentation? Most signing operations with RSA sign a hash of the data to be signed. The hash would then be padded before applying the RSA algorithm. But your description sounds like you are not using a hash of the data. Some one have more information to help me! Thanks all On Tue, Dec 17, 2013 at 10:42 AM, Luciano Coelho e-Sec coe...@esec.com.br mailto:coe...@esec.com.br wrote: Use CAPI or PKCS#11 check the middleware of your smartcard. May be Safesign. Raul Rosetto Munoz munoz0r...@gmail.com mailto:munoz0r...@gmail.com escreveu: I think that the Card work fine with windows, but my problem is that I didnt find a Software that sign a file. I just need to find a software that sign a number! (Can Be on Windows!) Every thing start because And I just need to do that one time! could be any software! If some one have any opinion for sure will help me a lot! Thanks For all help! On Mon, Dec 16, 2013 at 7:18 PM, Sébastien Lorquet sebast...@lorquet.fr mailto:sebast...@lorquet.fr wrote: Hello there is no generic way to talk to a smart card. You need to either -get technical documentation for your card -reverse the card protocol by looking at the exchanges between the card and the application. That may not be sufficient if the card uses a dynamic authentication mechanism. before allowing the use of a private key to sign data, most card requires a pin presentation or mutual authentication. Best regards Sebastien Lorquet Le 16/12/2013 22:11, Raul Rosetto Munoz a écrit : Hello Douglas, I try many foruns, and all the time I get Unsupported card: opensc-tool --reader 0 --name Unsupported card Do you know how to find the real type of my card? I try pcsc_scan But I didnt find some name that I can compare with this list: https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-%28smart-cards-and-USB-tokens%29 pcsc_scan PC/SC device scanner V 1.4.18 (c) 2001-2011, Ludovic Rousseau ludovic.rouss...@free.fr mailto:ludovic.rouss...@free.fr Compiled with PC/SC lite version: 1.7.4 Using reader plug'n play mechanism Scanning present readers... 0: ACS ACR 38U-CCID 00 00 Mon Dec 16 19:05:21 2013 Reader 0: ACS ACR 38U-CCID 00 00 Card state: Card inserted, ATR: 3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E ATR: 3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E + TS = 3B -- Direct Convention + T0 = 7F, Y(1): 0111, K: 15 (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 TB(1) = 00 -- VPP is not electrically connected TC(1) = 00 -- Extra guard time: 0 + Historical bytes: 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E Category indicator byte: 80 (compact TLV data object) Tag: 5, len: 9 (card issuer's data) Card issuer data: 49 44 65 61 59 49 44 65 61 Tag: 6, len: C (pre-issuing data) Data: 5F 31 2E Possibly identified card (using /home/raul/.smartcard_list.txt): 3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E e-CNPJ issued by Fenacon (eID) http://www.fenacon.org.br Thanks For All Help. On Mon, Dec 16, 2013 at 5:28 PM, Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov wrote: On 12/16/2013 11:46 AM, Raul Rosetto Munoz wrote: Hello, That's my first time that I really need to understand how the smart card works. First of all I have with me a Brazilian Digital Document called e-CPF, this card is an Version V2 with 2048 bits and is part of IPC-BRAZIL. Every thing start because I need to sign my device serial number with my smart card, in the documentation that I need to follow just say that I need sign a number like 290953052 and after sign I need to get
Re: [Muscle] SmartCard sign number
On 12/16/2013 11:46 AM, Raul Rosetto Munoz wrote: Hello, That's my first time that I really need to understand how the smart card works. First of all I have with me a Brazilian Digital Document called e-CPF, this card is an Version V2 with 2048 bits and is part of IPC-BRAZIL. Every thing start because I need to sign my device serial number with my smart card, in the documentation that I need to follow just say that I need sign a number like 290953052 and after sign I need to get an data string in base64, followed the PKCS #1 version 1.5. My First question, there is an chance to outsource the private key inside the smart card? No. That is the point of a smart card, the private key can not be read. It can only be used for decryption or signing. (The public key in a certificate is used for encryption or verifying signatures.) (The issuer of the card may be able to read it, but not ordinary users.) I asked that because if I get the private key I can do that using openssl. You might be able to use OpenSSL, if the card has an openssl engine or the card has a PKCS#11 library. (OpenSC has an openssl_engine for use with PKCS#11.) OpenSC also has PKCS#11 for some cards. Not clear if the e-cnpj is supported or not. People have asked in the past. https://github.com/OpenSC/OpenSC/wiki https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-%28smart-cards-and-USB-tokens%29 Google for: opensc smart card e-cnpj But if this happen I cant see an reason for smart cards work well. Im sorry to ask this basics questions but I realy got difficult to find informations. Thanks For All Help! -- *Raul Rosetto Muñoz* ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Re: [Muscle] SmartCard sign number
On 12/16/2013 3:11 PM, Raul Rosetto Munoz wrote: Hello Douglas, I try many foruns, and all the time I get Unsupported card: opensc-tool --reader 0 --name Unsupported card Do you know how to find the real type of my card? pcsc_scan is the best start. I try pcsc_scan But I didnt find some name that I can compare with this list: https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-%28smart-cards-and-USB-tokens%29 Then OpenSC does not support the card. Anyone can submit an OpenSC module for a card, but you would need the vendor's documentation on how the card works to write the module. Does Windows recognize the card? Does http://www.fenacon.org.br have a windows driver for the card? Does it work with FireFox or Thunderbird on Windows? pcsc_scan PC/SC device scanner V 1.4.18 (c) 2001-2011, Ludovic Rousseau ludovic.rouss...@free.fr mailto:ludovic.rouss...@free.fr Compiled with PC/SC lite version: 1.7.4 Using reader plug'n play mechanism Scanning present readers... 0: ACS ACR 38U-CCID 00 00 Mon Dec 16 19:05:21 2013 Reader 0: ACS ACR 38U-CCID 00 00 Card state: Card inserted, ATR: 3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E ATR: 3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E + TS = 3B -- Direct Convention + T0 = 7F, Y(1): 0111, K: 15 (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 TB(1) = 00 -- VPP is not electrically connected TC(1) = 00 -- Extra guard time: 0 + Historical bytes: 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E Category indicator byte: 80 (compact TLV data object) Tag: 5, len: 9 (card issuer's data) Card issuer data: 49 44 65 61 59 49 44 65 61 Tag: 6, len: C (pre-issuing data) Data: 5F 31 2E Possibly identified card (using /home/raul/.smartcard_list.txt): 3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E e-CNPJ issued by Fenacon (eID) http://www.fenacon.org.br Thanks For All Help. On Mon, Dec 16, 2013 at 5:28 PM, Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov wrote: On 12/16/2013 11:46 AM, Raul Rosetto Munoz wrote: Hello, That's my first time that I really need to understand how the smart card works. First of all I have with me a Brazilian Digital Document called e-CPF, this card is an Version V2 with 2048 bits and is part of IPC-BRAZIL. Every thing start because I need to sign my device serial number with my smart card, in the documentation that I need to follow just say that I need sign a number like 290953052 and after sign I need to get an data string in base64, followed the PKCS #1 version 1.5. My First question, there is an chance to outsource the private key inside the smart card? No. That is the point of a smart card, the private key can not be read. It can only be used for decryption or signing. (The public key in a certificate is used for encryption or verifying signatures.) (The issuer of the card may be able to read it, but not ordinary users.) I asked that because if I get the private key I can do that using openssl. You might be able to use OpenSSL, if the card has an openssl engine or the card has a PKCS#11 library. (OpenSC has an openssl_engine for use with PKCS#11.) OpenSC also has PKCS#11 for some cards. Not clear if the e-cnpj is supported or not. People have asked in the past. https://github.com/OpenSC/__OpenSC/wiki https://github.com/OpenSC/OpenSC/wiki https://github.com/OpenSC/__OpenSC/wiki/Supported-__hardware-%28smart-cards-and-__USB-tokens%29 https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-%28smart-cards-and-USB-tokens%29 Google for: opensc smart card e-cnpj But if this happen I cant see an reason for smart cards work well. Im sorry to ask this basics questions but I realy got difficult to find informations. Thanks For All Help! -- *Raul Rosetto Muñoz* _ Muscle mailing list Muscle@lists.musclecard.com mailto:Muscle@lists.musclecard.com http://lists.musclecard.com/__mailman/listinfo/muscle_lists.__musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _ Muscle mailing list Muscle@lists.musclecard.com mailto:Muscle@lists.musclecard.com http://lists.musclecard.com/__mailman/listinfo/muscle_lists.__musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- *Raul Rosetto Muñoz* ___ Muscle mailing list Muscle@lists.musclecard.com
Re: [Muscle] connection reset/no data returned errors in browser with pcsclite/coolkey
On 10/3/2013 10:51 AM, Howdy Dood
wrote:
Hello,
I have Fedora 19 on two machines.
I use libcoolkey to use a Common Access Card's
certificates to access my webmail athttp://www.foo.bar.gov
However, since upgrading to F19 on machine two,
although I am prompted for pin, etc, and certs show,
and I can choose the right cert, I get:
"
The connection was reset
The connection to the server was reset while the
page was loading."
and on a related site, I get:
"Unable to load the webpage because the server
sent no data.
Error code: ERR_EMPTY_RESPONSE"
On machine one, it works fine. I cannot figure out
what the problem is here. Same version of pcsc, same
version of libcoolkey... on machine 2, both firefox
and chrome have this problem.
Both machines are on the same network.
On machine two, if I open up virtualbox and go to
win8, and use CaC there, I can access the site with
IE.
Any site that requires email signature certificate on
card has this problem. If the site requires digital ID
certificate, it still works fine.
That sounds like the old version was caching the pin, and new
version is not, or not caching it correctly.
For PIV cards, (and all newer CAC cards are both) when the
signature key is used to do a crypto
operation, the previous operation to the card must have been a
verify i.e. PIN is sent.
You can run pcscd in debug mode, and watch the commands to the card
to get some more information.
And as a previous responder said, it could be because the *.gov web
site is down...
Thanks for help
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Re: [Muscle] connection reset/no data returned errors in browser with pcsclite/coolkey
On 10/3/2013 1:02 PM, Howdy Dood wrote: Douglas, thanks, but as I said, it works on the exact same site with another machine. The site is not down. I'm using it right now through virtualbox with windows 8. It seems to only have the problem when using the email certificate, but not the digital signature certificate(those sites work). What does the pcscd debugging show? Does it even get far enough to use the card? Are you missing some CA certificates or intermediate certificates on the F19? I believe that on DoD CAC cards, the two certificates may be signed by different CAs with different trust chains. On Thu, Oct 3, 2013 at 12:16 PM, Douglas E. Engert deeng...@anl.gov wrote: On 10/3/2013 10:51 AM, Howdy Dood wrote: Hello, I have Fedora 19 on two machines. I use libcoolkey to use a Common Access Card's certificates to access my webmail athttp://www.foo.bar.gov However, since upgrading to F19 on machine two, although I am prompted for pin, etc, and certs show, and I can choose the right cert, I get: " The connection was reset The connection to the server was reset while the page was loading." and on a related site, I get: "Unable to load the webpage because the server sent no data. Error code: ERR_EMPTY_RESPONSE" On machine one, it works fine. I cannot figure out what the problem is here. Same version of pcsc, same version of libcoolkey... on machine 2, both firefox and chrome have this problem. Both machines are on the same network. On machine two, if I open up virtualbox and go to win8, and use CaC there, I can access the site with IE. Any site that requires email signature certificate on card has this problem. If the site requires digital ID certificate, it still works fine. That sounds like the old version was caching the pin, and new version is not, or not caching it correctly. For PIV cards, (and all newer CAC cards are both) when the signature key is used to do a crypto operation, the previous operation to the card must have been a verify i.e. PIN is sent. You can run pcscd in debug mode, and watch the commands to the card to get some more information. And as a previous responder said, it could be because the *.gov web site is down...
Re: [Muscle] 16 character PIN
On 8/29/2013 4:23 AM, Kwan Hon Luen wrote: I am sorry folks, but I gave the wrong links in the previous email. The right link is as : http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp639.pdf Although the document is said as Oberthur V5 card, but the Applet v2.6.2B is correct. You say you are trying to verify a 16 character PIN. But which PIN? Section 5.5 Table 2 says the CSC uses secure channel. The card holder PIN does not, buts implies the ISO7816 the VERIFY operation. Section 9.4 says PIN (user I assume) can be between 6 and 256 digits or between 4 and 256 characters or digits. So the assumption is the PIN is sent as ASCII representation of the digit or characters, which are usually padded with 0xFF Section 9.5 says the user pin is zeroed, which on some cards I have seen this means all are 0x00, rather then 0x30 the ascii 0. Section 10.4 says the Card Holder Service PIN Execute (Verify CHV) This implies this is a standard ISO7816 Verify command. *BUT* I don't see where it sets sets the length of the pin, or how to read from the card what the length of the PIN should be. How do you know the PIN length is 16? Do you have a card to test with, and you know the PIN? (Or how to reset the user PIN if you make too many false attempts.) The most likely command using ISO7816 Verify would be with a 12 character password of Abcd012345678 padded with 4 0xFF 00 20 80 0f 41 62 63 64 30 31 32 33 34 35 36 37 38 FF FF FF FF -- The 80 says to use the application or DF reference data. If the Global PIN was used, it would be 00 A return of the 90 00 is success. a return of 63 Cx indicates you have x number of retries before the PIN is locked. On Thu, Aug 29, 2013 at 5:19 PM, Kwan Hon Luen kwanhonl...@gmail.com mailto:kwanhonl...@gmail.com wrote: It's not a PIV card but an Oberthur V7 card using ActivIdentity applet v2.6.2B which can be found at : http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp880.pdf On Wed, Aug 28, 2013 at 7:43 PM, Kwan Hon Luen kwanhonl...@gmail.com mailto:kwanhonl...@gmail.com wrote: Am trying to verify an Oberthur v7 card with ActivIdentity applet v2.6.2b with a 16 character PIN. How does the payload of the 16 char PIN look like? Thanks. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Re: [Muscle] 16 character PIN
On 8/28/2013 6:43 AM, Kwan Hon Luen wrote: Am trying to verify an Oberthur v7 card with ActivIdentity applet v2.6.2b with a 16 character PIN. How does the payload of the 16 char PIN look like? Sounds like a CAC or PIV card... http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1145.pdf The Oberthur id-one card supports SM so it may be a 8 digit pin over a SM channel. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1414.pdf The PIV specs say the PINs are 8 character. ActivIdentity may be using Secure Messaging so it looks like 16. Could also be the ActiveIdentity applet supports longer PINs, and the card can too. See if you can find your card and applet here: http://csrc.nist.gov/groups/STM/cmvp/validation.html#01 Thanks. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Re: [Muscle] How do we unblock a smart card
On 6/28/2013 12:02 AM, Anand Renju wrote: Hi, Is there any way to unblock a smart card when its master password is blocked? Depends on the card and what you mean by master password. Most card have a user PIN and Pin Unblocking Key (PUK) The PUK is used to reset the user PIN. The card admin would have the PUK. If the PUK is blocked, it usually means you have to get a new card. Thanks, -Renju ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Re: [Muscle] How do we disable the Firefox PIN dialog for PIN PAD Readers?
On 6/27/2013 2:41 AM, Anand Renju wrote: Hi Douglas, From where i can get this pkcs11-spy tool. I installed opensc-0.13.0, but it doesn't have this tool. It should be C:\Program Files\OpenSC Project\PKCS11-Spy\pkcs11-spy.dll Its a PKCS#11 driver that logs the activity of calls and returns of another PKCS#11 lib or dll that you specify via environment variables or on Windows the registry. See this as to where in the registry to set the module and output: https://www.opensc-project.org/opensc/wiki/WindowsInstaller You install pkcs11-spy.dll as a Firefox Security Device in place of yours. I have not used it on Windows lately, It should be in 0.13.0. Thanks, -Renju On Wed, Jun 26, 2013 at 7:02 PM, Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov wrote: On 6/26/2013 1:44 AM, Ludovic Rousseau wrote: 2013/6/26 Anand Renju anand.renju.mailing.list@__gmail.com mailto:anand.renju.mailing.l...@gmail.com: Hi, Hello, I'm using a Xiring XI-SIGN USB V2 PinPad reader with Firefox application, i have IAS ECC Middleware installed which provides the gclib.dll PKCS#11 module for Firefox. The problem i'm facing is when i click on 'Log in' button from Device Manager after selecting ECC eID module/device (Firefox - Options-Encryption-Security Devices ), Firefox pops up a dialog for entering the PIN. Instead asking PIN here, i 'm expecting a request for entering PIN at the PinPad reader display. At ccid side, i should get 0x42330006 control code. Is there any way disable this Pin Dialog from Firefox side. I'm using Firefox 21.0 You are using a proprietary PKCS#11 library on Windows (gclib.dll). You should contact the software provider support team. Also see: https://bugzilla.mozilla.org/__show_bug.cgi?id=295963 https://bugzilla.mozilla.org/show_bug.cgi?id=295963 You could also use the OpenSC pkcs11-spy to see the PKCS#11 calls. See if the gclib.dll returns CKF_PROTECTED_AUTHENTICATION___PATH This woulds show if it is a FireFox problem or the gclib.dll problem. Regards, -- Dr. Ludovic Rousseau _ Muscle mailing list Muscle@lists.musclecard.com mailto:Muscle@lists.musclecard.com http://lists.musclecard.com/__mailman/listinfo/muscle_lists.__musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _ Muscle mailing list Muscle@lists.musclecard.com mailto:Muscle@lists.musclecard.com http://lists.musclecard.com/__mailman/listinfo/muscle_lists.__musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Re: [Muscle] How do we disable the Firefox PIN dialog for PIN PAD Readers?
On 6/26/2013 1:44 AM, Ludovic Rousseau wrote: 2013/6/26 Anand Renju anand.renju.mailing.l...@gmail.com: Hi, Hello, I'm using a Xiring XI-SIGN USB V2 PinPad reader with Firefox application, i have IAS ECC Middleware installed which provides the gclib.dll PKCS#11 module for Firefox. The problem i'm facing is when i click on 'Log in' button from Device Manager after selecting ECC eID module/device (Firefox - Options-Encryption-Security Devices ), Firefox pops up a dialog for entering the PIN. Instead asking PIN here, i 'm expecting a request for entering PIN at the PinPad reader display. At ccid side, i should get 0x42330006 control code. Is there any way disable this Pin Dialog from Firefox side. I'm using Firefox 21.0 You are using a proprietary PKCS#11 library on Windows (gclib.dll). You should contact the software provider support team. Also see: https://bugzilla.mozilla.org/show_bug.cgi?id=295963 You could also use the OpenSC pkcs11-spy to see the PKCS#11 calls. See if the gclib.dll returns CKF_PROTECTED_AUTHENTICATION_PATH This woulds show if it is a FireFox problem or the gclib.dll problem. Regards, -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
[Muscle] Muscle smart card Applet various versions from M.U.S.C.L.E. and OpenSC
I am not using the Muscle card applet, but was looking looking at the OpenSC debug log for this thread: Re: [opensc-devel] The smart card reader is known as VMware Virtual USB CCID 00 00 in linux ??!! The OpenSC card-muscle.c (0.12.2 or 0.13.0) is looking for PROTO_VERSION_MAJOR=1 The author of the original note said: I've loaded and initialized Muscle applet (0.9.11) on it. This appears in the log that GET_STATUS is returning: 00 01 00 05 ... i.e. PROTO_VERSION_MAJOR=0, PROTO_VERSION_MINOR=1 This version from 2003-12-19, does not sound like the latest to me... Yet in the Muscle CVS archives: http://anonscm.debian.org/viewvc/muscleplugins/trunk/MCardApplet/ as of 4 years ago has version.properties has: APPLET_VERSION_MAJOR=0 APPLET_VERSION_MINOR=9 PROTO_VERSION_MAJOR=1 PROTO_VERSION_MINOR=3 And there have been changes in the SVN 9 months ago, 2 years ago and 3 years ago, which are not reflected in the Download page: https://alioth.debian.org/frs/?group_id=30111 Can the download versions be update, or the page change to say compile it yourself? Or point to the OpenSC page? Then on OpenSC-project: http://www.opensc-project.org/opensc/wiki/MuscleApplet it says: OpenSC supports the Muscle applet, available from Debian SVN: svn co svn://svn.debian.org/muscleplugins/trunk/MCardApplet (This appears to be the same SVN as on the Muscle page, revision 298 from 9 months ago.) An updated version, targeting recent JavaCard 2.2.2 cards with extended APDUs is available from github: http://github.com/martinpaljak/MuscleApplet This github is 3 years old, yet changes where made to the Muscle SVN 9 months ago. https://github.com/martinpaljak/MuscleApplet/blob/master/src/com/musclecard/CardEdge/CardEdge.java (3 years old) buffer[pos++] = (byte) 1; // Major Card Edge Protocol version n. buffer[pos++] = (byte) 3; // Minor Card Edge Protocol version n. buffer[pos++] = (byte) 0; // Major Applet version n. buffer[pos++] = (byte) 9; // Minor Applet version n. Which is in line with the PROTO_VERSION_MAJOR the OpenSC code is looking for. Can Martin and Ludovic get together and get these versions in sync, and make it so others don't download the 9 year old version? Thanks. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Re: [Muscle] pcscd / firefox / ubuntu on android
On 10/18/2012 11:23 AM, James Southwell wrote: Running Firefox 11.0 Installed opensc and websites requiring signature certificate work without issue. Websites that require email signature error out. Good to hear. There are a few issues with using the the PIV signing cert/key from OpenSC-0.12.2 that are fixed in the upcoming 0.13.0 release. They deal with the card enforcing the use of the PIN just before any crypto operation using the signing key. OpenSC 0.12.2 will recognize the PKCS#15 user_consent flag on these types of keys and not cache a PIN in that case. But NSS used by FF and TB don't yet understand the PKCS#11 CKA_ALWAYS_AUTHENTICATE attribute. Bug reports on this go back to 2006. The fixes are in the pipeline for NSS 3.14 but not yet in released FF or TB. For more info: Google for: OpenSC CKA_ALWAYS_AUTHENTICATE NSS So until FF and TB get the fixes, OpenSC-0.13.0 adds a new option to the opensc.conf file to cache the pin to accommodate older applications. pin_cache_ignore_user_consent = true; Webpage shows: Secure Connection Failed An error occurred during a connection to x.navy.mil. The operation failed because the PKCS#11 token is not logged in. (Error code: sec_error_token_not_logged_in) opensc 0.12.2-2ubuntu1 Smart card utilities with support for PKCS#15 compatible cards pcscd 1.7.4-2ubuntu2 Middleware to access a smart card using PC/SC (daemon side) libpcsclite1 1.7.4-2ubuntu2 Middleware to access a smart card using PC/SC (library) Thank you for information already provided. Jim ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pcscd / firefox / ubuntu on android
Ask on the opensc-mail list. there is a 0.13.0-rc1 available. On 10/18/2012 7:40 PM, James Southwell wrote: When is opensc 0.13 going to be released? Thanks ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Fwd: pcscd / firefox / ubuntu on android
___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] ANY possibilities of using google chrome with cac reader?
On 7/3/2012 7:27 AM, Jean-Michel Pouré - GOOZE wrote: Le dimanche 24 juin 2012 à 20:08 -0500, Howdy Doody a écrit : I have been unable to find an answer to this anywhere else, but is there any way, at all, to use my cac reader in Linux with google chrome, or am I doomed to have to continue using firefox with cackey or coolkey? In addition to all the other comments, Newer CAC smartcards are being issued as dual CAC and PIV cards. OpenSC supports the PIV. Google for: CAC PIV dual applications It should work with any OpenSC supported smartcard. Please follow this guide: http://www.gooze.eu/howto/smartcard-quickstarter-guide It was not tested with Google chrome but OpenSC should work as well. Kind regards, ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Error loading MuscleCard Applet
On 1/31/2012 11:44 AM, Guilherme André Welter wrote: Hello, i'm a student of Information Systems of Federal University of Santa Catarina - Brazil. I work in LabSEC http://www.labsec.ufsc.br/ (Laboratory of Computing Security) and until now i'm researching Java card tecnology, more specifically the MuscleCard Applet which are presenting some problems during the applet upload onto smartcard. What i've done so far was download the applet (.cap) on MUSCLE Project site and try to upload it onto smartcard, unfortunately the download link of MuscleCard Applet Loader is not working so i research how do this without it. Using GPShell, the commands that i used was: *(Smart card used: Oberthur ID-One Cosmo V7.0.1)* Are you sure the card is GP 2.0.1? The ID-ONE Cosmos V7.0-n cards I have are GP 2.1.1. $ gpshell mode_201 enable_trace establish_context card_connect select -AID a0 00 00 01 51 00 00 open_sc -security 3 -keyind 0 -keyver 0 -key 00 00 -keyDerivation emvcps11 install -file CardEdge.cap -instParam 00 -priv 2 card_disconnect release_context Returning this error *read_executable_load_file_parameters() returns 0x0096DB3B* I'd like to know if has sommething wrong in my script or if the card is not compatible with MuscleCard Applet. Using capdump of JCDK on the applet the return is *java.util.zip.ZipException: error in opening zip file* Also, i've downloaded the source at https://github.com/martinpaljak/MuscleApplet and i compiled it. With that appleti've succeeded to upload it onto smartcard but using this bash command after this all opensc-tool -s 00:A4:04:00:06:A0:00:00:00:01:01 -s B0:2A:00:00:38:08:4D:75:73:63:6C:65:30:30:04:01:08:30:30:30:30:30:30:30:30:08:30:30:30:30:30:30:30:30:05:02:08:30:30:30:30:30:30:30:30:08:30:30:30:30:30:30:30:30:00:00:17:70:00:02:01 looking at the OpenSC card-muscle.c, msc_select_applet is called with a length of 5, not 6, so try: opensc-tool -s 00:A4:04:00:05:A0:00:00:00:01 This bash command return *Received (SW1=0x69, SW2=0x99)* for both APDUs. Thank you. -- Guilherme André Welter Laboratório de Segurança em Computação - LabSEC Universidade Federal de Santa Catarina - UFSC ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Regarding OCF access to smart card
On 12/20/2011 7:24 AM, Tarun Khandelwal wrote: Hi, I am trying to use OCF framework to access smart card. I have deployed OCF framework on linux machine. I have downloaded the reference from below mention site *http://www.openscdp.org/ocf/download.html* But, there is no way to compile the samples. In site it is only mention to use *java demos.samples.GetCardID* when I tried , it gives me NoClassDeffoundError. I didn't understand, how it will find .class files . as there is no way to compile the samples. I have install ocf framework as per below mention link *http://www.mail-archive.com/opencard-dist@opencard.org/msg01435.html* I am a newbie , can you please help me with this. The OCF is fairly old, around 2001, but does this help: http://www.gemalto.com/techno/opencard/faqs/install-faq-qna.html Under troubleshooting #6. Thanks in advance. Best Regards, Tarun Khandelwal ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] SafeNet Smartcard 330
On 11/4/2011 6:09 AM, anze.stojilko...@policija.si wrote:
I modified opensc.conf and I added this:
card_atr
3b:ff:13:00:00:81:31:fe:4d:80:25:a0:00:00:00:56:57:44:4b:33:33:30:06:00:d2 {
name = PIV-II;
driver = muscle;
This is forcing the the muscle driver to use the card, but
the card is not a muscle card, thus the unsupported card
message, and also bypassing where ever the segfault was at.
Rather doing this, can you remove those lines, and change these lines
to turn on debugging to a file:
--- opensc.conf.new Fri Sep 23 11:00:35 2011
+++ opensc.conf Wed May 11 16:10:52 2011
@@ -12,14 +12,16 @@
# A greater value means more debug info.
# Default: 0
#
- debug = 0;
+debug = 7;
+#debug = 0;
+
# The file to which debug output will be written
#
# Special values 'stdout' and 'stderr' are recognized.
# Default: stderr
#
- # debug_file = /tmp/opensc-debug.log;
+ debug_file = /tmp/opensc-debug.log;
# debug_file = C:\Documents and Settings\All
Users\Documents\opensc-debug.log;
# PKCS#15 initialization / personalization
@@ -447,7 +449,6 @@
}
}
Then run the tests again, and send the debug output to the
list or myself?
Each command will append to the debug file, so if you run more then one
command, you may want to copy the file between commands and send separate
files. The debug trace may show what is was doing just before the segfault.
And now, there is no segmentation fault, but I am still not sure which card
driver do I have to use.
This may be a PIV card as they appear to sell them, but it is not
initialized in any way, and the code may not have anticipated such
a card being used.
According to ATR, my card is:
Possibly identified card: Datakey DCOS model 330 (DKCCOS 6.0 token)
# Now, pkcs11-tool --module path/to/opensc-pkcs11.so-L gives me this:
[opensc-pkcs11] pkcs15.c:799:sc_pkcs15_bind: returning with: Unsupported card
Available slots:
Slot 0 (empty)
Slot 1 (empty)
Slot 2 (empty)
Slot 3 (empty)
Slot 4 (empty)
Slot 5 (empty)
Slot 6 (empty)
Slot 7 (empty)
Slot 8 (empty)
Slot 9 (empty)
Slot 10 (empty)
Slot 11 (empty)
Slot 12 (empty)
Slot 13 (empty)
Slot 14 (empty)
Slot 15 (empty)
# opensc-tool -l gives me this:
Readers known about:
Nr. Driver Name
0 openct OpenCT reader (detached)
1 openct OpenCT reader (detached)
2 pcsc OMNIKEY CardMan 3x21 00 00
# pkcs11-tool -I
[opensc-pkcs11] pkcs15.c:799:sc_pkcs15_bind: returning with: Unsupported card
Cryptoki version 2.20
Manufacturer OpenSC (www.opensc-project.org)
Library smart card PKCS#11 API (ver 0.0)
I hope those infos help you to know how to help me, becouse I am really stuck
here.
Thank you
Od: Douglas E. Engert deeng...@anl.gov
Za: muscle@lists.musclecard.com
Datum: 26.10.2011 16:57
Zadeva: Re: [Muscle] SafeNet Smartcard 330
Poslal: muscle-boun...@lists.musclecard.com
This discussion should be moved to opensc-u...@lists.opensc-project.org or
OpenSC-devel opensc-de...@lists.opensc-project.org
On 10/26/2011 2:37 AM, anze.stojilko...@policija.si wrote:
Yes, the system finds SafeNet card as PIV-II card*.*
How can I initialize the card?
The intent of the OpenSC PIV card support is to support pre-issued
PIV cards by supporting the NIST 800-73 standards. These standards do
not define a full set of card management operations but leave that up
to the vendors. The PIV cards where not designed for user provisioning.
See: http://www.opensc-project.org/opensc/wiki/UnitedStatesPIV
But OpenSC has the piv-tool to allow a PIV card to be partially
initialized/provisioned for test purposes. It will require some commands
that are vendor specific. You will need to get these commands from the
card vendor, as well as any initial PINs and keys used during
initialization. Use of the piv-tool does not replace the need
for a good card management system.
SafeNet offers two card management products that may or may not work
with the PIV card.
http://www.safenet-inc.com/products/data-protection/two-factor-authentication/etoken-tms/
http://www.safenet-inc.com/products/data-protection/two-factor-authentication/myid-card-management-center/
# opensc-tool -I opensc 0.11.13 [gcc 4.5.0 20100604 [gcc-4_5-branch
revision 160292]]
Enabled features: zlib readline iconv openssl openct
pcsc(/usr/lib/libpcsclite.so.1) nsplugin
# opensc-tool -a
Using reader with a card: OMNIKEY CardMan 3x21 00 00
3b:ff:13:00:00:81:31:fe:4d:80:25:a0:00:00:00:56:57:44:4b:33:33:30:06:00:d2
pkcs11-tool --module path/to/opensc-pkcs11.so-L still gives me
Segmentation fault
# gdb --args pkcs11-tool -I
GNU gdb (GDB) SUSE (7.1-3.12)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
Re: [Muscle] SafeNet Smartcard 330
This discussion should be moved to opensc-u...@lists.opensc-project.org or OpenSC-devel opensc-de...@lists.opensc-project.org On 10/26/2011 2:37 AM, anze.stojilko...@policija.si wrote: Yes, the system finds SafeNet card as PIV-II card*.* How can I initialize the card? The intent of the OpenSC PIV card support is to support pre-issued PIV cards by supporting the NIST 800-73 standards. These standards do not define a full set of card management operations but leave that up to the vendors. The PIV cards where not designed for user provisioning. See: http://www.opensc-project.org/opensc/wiki/UnitedStatesPIV But OpenSC has the piv-tool to allow a PIV card to be partially initialized/provisioned for test purposes. It will require some commands that are vendor specific. You will need to get these commands from the card vendor, as well as any initial PINs and keys used during initialization. Use of the piv-tool does not replace the need for a good card management system. SafeNet offers two card management products that may or may not work with the PIV card. http://www.safenet-inc.com/products/data-protection/two-factor-authentication/etoken-tms/ http://www.safenet-inc.com/products/data-protection/two-factor-authentication/myid-card-management-center/ # opensc-tool -I opensc 0.11.13 [gcc 4.5.0 20100604 [gcc-4_5-branch revision 160292]] Enabled features: zlib readline iconv openssl openct pcsc(/usr/lib/libpcsclite.so.1) nsplugin # opensc-tool -a Using reader with a card: OMNIKEY CardMan 3x21 00 00 3b:ff:13:00:00:81:31:fe:4d:80:25:a0:00:00:00:56:57:44:4b:33:33:30:06:00:d2 pkcs11-tool --module path/to/opensc-pkcs11.so-L still gives me Segmentation fault # gdb --args pkcs11-tool -I GNU gdb (GDB) SUSE (7.1-3.12) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i586-suse-linux. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/pkcs11-tool...Missing separate debuginfo for /usr/bin/pkcs11-tool Try: zypper install -C debuginfo(build-id)=7034486b591f3d39c4066653d8c803b3f1740c3a (no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/pkcs11-tool -I Missing separate debuginfo for /lib/ld-linux.so.2 Try: zypper install -C debuginfo(build-id)=22e2b3718e8271a0d899156a796b0a90bc4dc391 Missing separate debuginfo for /usr/lib/libopensc.so.2 Try: zypper install -C debuginfo(build-id)=a2968b909d9f77159f6ceac9e27292f40329cea2 Missing separate debuginfo for /lib/libcrypto.so.1.0.0 Try: zypper install -C debuginfo(build-id)=748b7a6af35635f6d49b3e490bc63326a29d90f4 Missing separate debuginfo for /usr/lib/libltdl.so.7 Try: zypper install -C debuginfo(build-id)=5b5598e8ebd310d83acde7a67ba6894627004523 Missing separate debuginfo for /lib/libpthread.so.0 Try: zypper install -C debuginfo(build-id)=ebd849d5f5cebe33657f871a32bf0eb34132e8d1 [Thread debugging using libthread_db enabled] Missing separate debuginfo for /lib/libc.so.6 Try: zypper install -C debuginfo(build-id)=62a8bfd7732322fa6b9c39d39a830a8028804534 Missing separate debuginfo for /usr/lib/libopenct.so.1 Try: zypper install -C debuginfo(build-id)=f7efb05f0795f9f22db4a941c6c5cb93b3c0a0ee Missing separate debuginfo for /lib/libz.so.1 Try: zypper install -C debuginfo(build-id)=afddd839a6c18dd308b04b5289c56cc3abd1384f Missing separate debuginfo for /usr/lib/libscconf.so.2 Try: zypper install -C debuginfo(build-id)=a2730fd63a824c6c74d4405d741d1a15b6b912de Missing separate debuginfo for /lib/libdl.so.2 Try: zypper install -C debuginfo(build-id)=20519b5f2874a1cf29e149802cfbef0db142633f Missing separate debuginfo for /usr/lib/opensc-pkcs11.so Try: zypper install -C debuginfo(build-id)=96f91af434b1fad440a1568057509c47e9b3ef6f Missing separate debuginfo for /usr/lib/libpkcs15init.so.2 Try: zypper install -C debuginfo(build-id)=2c1a3b91716eb49aae5a31ba08c3e94caeacd221 Missing separate debuginfo for /usr/lib/libpcsclite.so.1 Try: zypper install -C debuginfo(build-id)=02dd0ec78d070922bcb6dbb7d47558f13ddb26a2 Program received signal SIGSEGV, Segmentation fault. 0xb7f34bb7 in ?? () from /usr/lib/libopensc.so.2 In addition to what Martin said about a newer version, and using the debuginfo, The opensc.conf file has a number of debugging options that could help with finding any problems: 15c15,17 debug = 0; --- debug = 7; #debug = 0; 22c24 # debug_file = /tmp/opensc-debug.log; --- debug_file = /tmp/opensc-debug.log; I really appreciate your help! Od: Douglas E. Engert deeng...@anl.gov Za: muscle@lists.musclecard.com Datum: 25.10.2011 17:00 Zadeva: Re: [Muscle] SafeNet Smartcard 330 Poslal: muscle-boun...@lists.musclecard.com
Re: [Muscle] SafeNet Smartcard 330
On 10/25/2011 8:42 AM, anze.stojilko...@policija.si wrote: Hi, Any suggestions on how can I get my SafeNet Smartcard 330 work on openSuse? I have installed opensc and pkcs11. - If I type opensc-tool -n it returns; Using reader with a card: OMNIKEY CardMan 3x21 00 00 PIV-II card So the SafeNet card looks like a PIV-II card??? Has the card been initialized? Do you have the ATR from the card? opensc-tool -a What version of OpenSC version?: opensc-tool -i - pkcs11-tool --I returns; Segmentation fault With pkcs11-tool try the --module option to point to the opensc-pkcs11.so the --module option that is required. Then try it with the -L and -T and maybe the -O options. pkcs11-tool --module path/to/opensc-pkcs11.so -L If it still segfaults, try running with gdb: gdb --args pkcs11-tool -I run Sorry for lack of informations, but I am new on this and I don't know what you need to help me. Thank you for your help ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] multiple smartcard reader with pcscd 1.6.1 on a Solaris 10 Sparc 64 server
On 11/2/2010 2:33 AM, Ludovic Rousseau wrote: 2010/11/1roland.r...@t-systems.com: Hi, Hello, currently I'm testing the pcscd (version 1.6.1, ccid 1.3.13, compiled with Sun Studio 12) with many Kobil t...@nk smartcard readers connected at a Solaris 10 Sparc 64 Box via 2 usb hubs. If I connect more the 9 readers, I get the following error messages: First the startup messages for the first reader: #/usr/local/sbin/pcscd -df pcscdaemon.c:223:() pcscd set to foreground with debug send to stderr 0714 configfile.l:282:() Parsing conf file: /usr/local/etc/reader.conf 0204 pcscdaemon.c:528:() pcsc-lite 1.6.1 daemon ready. 02181081 hotplug_libusb.c:500:() Adding USB device: /dev/usb:d46.3010/0 9005 readerfactory.c:979:() Attempting startup of KOBIL EMV CAP - SecOVID Reader III (SD101316817) 00 00 using /usr/local/pcsc/drivers/ifd-ccid.bundle/Contents/Solaris/libccid.so 1712 readerfactory.c:849:() Loading IFD Handler 3.0 0405 ifdhandler.c:1715:() Driver version: 1.3.13 2527 ifdhandler.c:1728:() LogLevel?: 0x0003 2473 ifdhandler.c:1748:() DriverOptions?: 0x 0222 ifdhandler.c:82:() lun: 0, device: usb:0d46/3010:libusb:/dev/usb:d46.3010/0 5595 ccid_usb.c:284:() Manufacturer: Ludovic Rousseau (ludovic.rouss...@free.fr) 2461 ccid_usb.c:294:() ProductString?: Generic CCID driver 2455 ccid_usb.c:300:() Copyright: This driver is protected by terms of the GNU Lesser General Public License version 2.1, or (at your option) any later version. 00471855 ccid_usb.c:512:() Found Vendor/Product: 0D46/3010 (KOBIL EMV CAP - SecOVID Reader III) 0212 ccid_usb.c:515:() Using USB bus/device: /dev/usb/d46.3010/0 --- here the daemon waits always for 10 seconds, don't know why, it's the same behavior for each reader 10013337 ccid_usb.c:920:() IFD does not support GET_DATA_RATES request: I/O error 00031550 ifdhandler.c:394:() tag: 0xFB0, usb:0d46/3010:libusb:/dev/usb:d46.3010/0 (lun: 0) 0221 readerfactory.c:273:() Using the pcscd polling thread 2090 ifdhandler.c:394:() tag: 0xFAE, usb:0d46/3010:libusb:/dev/usb:d46.3010/0 (lun: 0) 0213 ifdhandler.c:483:() Reader supports 1 slot(s) ... Now the messages after connecting the 10th reader: 0200 ccid_usb.c:441:() USB device /dev/usb/d46.3010/8 already in use. Checking next one. 0569 ccid_usb.c:512:() Found Vendor/Product: 0D46/3010 (KOBIL EMV CAP - SecOVID Reader III) 0211 ccid_usb.c:515:() Using USB bus/device: /dev/usb/d46.3010/9 10015777 ccid_usb.c:920:() IFD does not support GET_DATA_RATES request: I/O error 00020537 ccid_usb.c:619:() usb_bulk_write(/dev/usb/d46.3010/9): Not enough space 0702 ccid_usb.c:619:() usb_bulk_write(/dev/usb/d46.3010/9): Not enough space 0701 ccid_usb.c:619:() usb_bulk_write(/dev/usb/d46.3010/9): Not enough space 0225 ifdhandler.c:137:() failed 0344 readerfactory.c:1010:() Open Port 29 Failed (usb:0d46/3010:libusb:/dev/usb) 0206 readerfactory.c:257:() KOBIL EMV CAP - SecOVID Reader III (SD101316366) init failed. 0304 hotplug_libusb.c:410:() Driver ifd-ccid.bundle does not support IFD_GENERATE_HOTPLUG. Using active polling instead. 0204 hotplug_libusb.c:420:() Polling forced every 1 second(s) Does anybody knows, what the reason for these messages? Do I have a problem with the Solaris 10 libusb driver? I would also suspect a limitation of the Solaris 10 libusb driver. I do not have a limitation to 10 readers in the CCID driver. If you have the source code the libusb for Solaris you should have a look inside. On Solaris 10, /usr/sfw/share/doc/libusb/libusb.txt has some debugging information that might also help to foind the problem. /usr/sfw/include/usb.h has a number of defines that might be getting reached, three endpoints per reader could reach the USB_MAXENDPOINTS? #define USB_MAXENDPOINTS32 #define USB_MAXINTERFACES 32 #define USB_MAXALTSETTING 128 /* Hard limit */ #define USB_MAXCONFIG 8 Note: the Solaris libusb is based on 0.1.8. There is no libusb based on 1.0. Newer versions of ccid require 1.0. In August I started to look at porting libusb 1.0 but did not get very far. Bye -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pcsc and gdm
You may have a library conflict as GDM and pam will have loaded into the process
almost every shared labrary, from X11, LDAP, nss, Kerberos, OpenSSL ...
make sure your pam module is linked as a module, so it gets the right versions
of routines, not some duplicate named routine from some previously loaded
module.
You can also have your module write a lot of debug output to syslog.
Have you looked at any of the pam PKCS#11 modules? Google for: gdm smart card.
For example there are a number of pam_krb5 modules that can use smart cards
to authenticate to Kerberos or Windows AD using the Kerberos PKINIT protocol,
and they work from GDM, and use pcscd. There is also the OpenSC pam_pkcs11
module
for local authentication.
On 10/4/2010 8:41 PM, Matthew Brown wrote:
Hello,
I realize this has been discussed before, yet I failed to find something
directly relevant to my issue.
I am somewhat new to writing PAM modules and using PCSC, however, after
much research and trying I cannot get around this.
Although my final problem is entrenched in a larger set of code, I have
managed to isolate the issue I am experiencing to a fairly simple PAM
module that I have put into the gdm stack. Basically, in
pam_authenticate, I do the following (pseudo-code) :
pam_prompt : enter YES to try the card
{
if YES, then perform a very basic PCSC set of calls :
GetContext
GetReaders
GetStateChange - passing UNAWARE to get the current state
GetStateChange - block with some reasonable timeout, awaiting a state
other than the initial
ReleaseContext
pam_prompt: done. card event or timeout over. enter anything to continue
}
return PAM_SUCCESS
This module is entered as auth required test_module.so, which will
return success and continue to PAM_UNIX and ask for a username and password.
When I run the same set of PCSC calls in a simple app from the command
line, i.e. NOT from within the GDM PAM environment, everything is fine.
However, when I actually logout and get GDM to run my module, it is my
belief that any actual state change that occurs with my single usb card
reader causes PAM to restart the GDM login process. What I experience is
the first prompt, to which I enter YES, then either insert or remove
the card, and I quickly see the final done. card event prompt, yet
very quickly it will reset the process - the screen blinks and I am
prompted again with enter YES If I initially enter NO, I am
taken right to the standard username prompt, as expected.
A look at the /var/log/messages file reveals a few hints :
gdm[pid] : conversation failed
gdm[pid] : gdm_cleanup_children: child [...] crashed of signal 11
gdm[pid] : gdm_cleanup_children: slave crashed, killing it's children
and /var/log/secure has something like this :
pam_succeed_if(gdm:auth) error retrieving user name: Conversation error
This looks to me like a segfault occured somewhere, the result of which
is that PAM was unable to get my username, either because of or after
which it restarts. Yet as I said, when I run this exact set of PCSC
calls as a simple command line application through valgrind and gdb, all
is well. If I use this PAM module through SU, it also works without a hitch.
Any advice or help is appreciated.
Thanks much
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Patch for Problem with Pin-Pad reader on Big Endian Machine
Thanks, Now the main issue with Solaris is a lack of libusb-1.0. I started to look at this, and it is not trivial. On 9/14/2010 4:30 AM, Ludovic Rousseau wrote: 2010/8/13 Douglas E. Engertdeeng...@anl.gov: Two weeks ago, I reported problems with using pin pad readers on big endian machines. During the mail exchanges it was pointed out that the PCSC standards have changed and are not clear on how the uint16_t and uint32_t values in the PIN_VERIFY_STRUCTURE and PIN_MODIFY_STRUCTURE should be passed. In addition the OpenSC defined its own version of the reader.h and did not define the HOST_TO_CCID_16 and HOST_TO_CCID_32 correctly. Attached is a patch against ccid-1.3.13 src/command.c that will test the ulDataLength to see if it is big endian, on a big endian machine. If so, it will swap the bytes in the 3 fields to be little endian. Thus if the fields are passed in in either little or big endian the fields will be converted to little endian, ready for the pin pad reader, and the code will work on any machine. This was tested on a Solaris 10 sparc system with an Omnikey 3821 reader, using ccid-1.3.3 and pcsc-lite-1.6.1, and OpenSC-svn. I can't test against ccid-1.4 as it is now using libusb-1.0, and this is not supported on Solaris. It looks like the code change should still work with ccid-1.4. Patch applied in revision 5252 http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2010-September/004804.html Thanks. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [MUSCLE] pcscd isn't working properly at startup (Ubuntu 10.04)
- + Historical bytes: 80 Category indicator byte: 80 (compact TLV data object) + TCK = 80 (correct checksum) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 81 80 01 80 80 Mifare DESFire Tue Sep 7 11:35:49 2010 Reader 1: Gemalto Prox-DU [Prox-DU Contactless_10500161] (10500161) 01 00 Card state: Card removed, I'm pretty sure that there must be a way to solve it without needing to restart pcscd every time. I'll be very grateful if you could give me a piece of advice. Thanks in advance, Francisco ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] Patch for Problem with Pin-Pad reader on Big Endian Machine
Two weeks ago, I reported problems with using pin pad readers on big
endian machines. During the mail exchanges it was pointed out that the
PCSC standards have changed and are not clear on how the uint16_t and
uint32_t values in the PIN_VERIFY_STRUCTURE and PIN_MODIFY_STRUCTURE
should be passed.
In addition the OpenSC defined its own version of the reader.h and did
not define the HOST_TO_CCID_16 and HOST_TO_CCID_32 correctly.
Attached is a patch against ccid-1.3.13 src/command.c that will test
the ulDataLength to see if it is big endian, on a big endian machine.
If so, it will swap the bytes in the 3 fields to be little endian.
Thus if the fields are passed in in either little or big endian
the fields will be converted to little endian, ready for the pin pad
reader, and the code will work on any machine.
This was tested on a Solaris 10 sparc system with an Omnikey 3821
reader, using ccid-1.3.3 and pcsc-lite-1.6.1, and OpenSC-svn.
I can't test against ccid-1.4 as it is now using libusb-1.0, and this
is not supported on Solaris. It looks like the code change should
still work with ccid-1.4.
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--- ./src/,commands.c Fri Jun 4 07:31:15 2010
+++ ./src/commands.cFri Aug 13 10:38:24 2010
@@ -51,6 +51,12 @@
#define max( a, b ) ( ( ( a ) ( b ) ) ? ( a ) : ( b ) )
#define offsetof(TYPE, MEMBER) ((size_t) ((TYPE *)0)-MEMBER)
+#ifndef BSWAP_16
+#define BSWAP_8(x) ((x) 0xff)
+#define BSWAP_16(x) ((BSWAP_8(x) 8) | BSWAP_8((x) 8))
+#define BSWAP_32(x) ((BSWAP_16(x) 16) | BSWAP_16((x) 16))
+#endif
+
/* internal functions */
static RESPONSECODE CmdXfrBlockAPDU_extended(unsigned int reader_index,
unsigned int tx_length, unsigned char tx_buffer[], unsigned int
*rx_length,
@@ -69,6 +75,7 @@
unsigned char rx_buffer[]);
static void i2dw(int value, unsigned char *buffer);
+static unsigned int bei2i(unsigned char *buffer);
/*
@@ -281,10 +288,12 @@
{
unsigned char cmd[11+14+CMD_BUF_SIZE];
unsigned int a, b;
+ PIN_VERIFY_STRUCTURE *pvs;
_ccid_descriptor *ccid_descriptor = get_ccid_descriptor(reader_index);
int old_read_timeout;
RESPONSECODE ret;
+ pvs = (PIN_VERIFY_STRUCTURE *)TxBuffer;
cmd[0] = 0x69; /* Secure */
cmd[5] = ccid_descriptor-bCurrentSlotIndex;/* slot number */
cmd[6] = (*ccid_descriptor-pbSeq)++;
@@ -307,6 +316,21 @@
return IFD_NOT_SUPPORTED;
}
+ /* On little endian machines we are all set. */
+ /* If on big endian machine and caller is using host byte order */
+
+ if (pvs-ulDataLength + 19 == TxLength
+ bei2i((unsigned char*)(pvs-ulDataLength)) ==
pvs-ulDataLength)
+ {
+ DEBUG_INFO(Reversing order from big to little endian\n);
+ /* If ulDataLength is big endian, assume others are too */
+ /* reverse the byte order for 3 fields */
+ pvs-wPINMaxExtraDigit = BSWAP_16(pvs-wPINMaxExtraDigit);
+ pvs-wLangId = BSWAP_16(pvs-wLangId);
+ pvs-ulDataLength = BSWAP_32(pvs-ulDataLength);
+ }
+ /* At this point we now have the above 3 variables in little endian */
+
if (dw2i(TxBuffer, 15) + 19 != TxLength) /* ulDataLength field
coherency */
{
DEBUG_INFO3(Wrong lengths: %d %d, dw2i(TxBuffer, 15) + 19,
TxLength);
@@ -496,6 +520,7 @@
{
unsigned char cmd[11+19+CMD_BUF_SIZE];
unsigned int a, b;
+ PIN_MODIFY_STRUCTURE *pms;
_ccid_descriptor *ccid_descriptor = get_ccid_descriptor(reader_index);
int old_read_timeout;
RESPONSECODE ret;
@@ -503,6 +528,7 @@
int bNumberMessages = 0; /* for GemPC Pinpad */
#endif
+ pms = (PIN_MODIFY_STRUCTURE *)TxBuffer;
cmd[0] = 0x69; /* Secure */
cmd[5] = ccid_descriptor-bCurrentSlotIndex;/* slot number */
cmd[6] = (*ccid_descriptor-pbSeq)++;
@@ -525,6 +551,22 @@
return IFD_NOT_SUPPORTED;
}
+ /* On little endian machines we are all set. */
+ /* If on big endian machine and caller is using host byte order */
+
+ if (pms-ulDataLength + 24 == TxLength
+ bei2i((unsigned char*)(pms-ulDataLength)) ==
pms-ulDataLength)
+ {
+ DEBUG_INFO(Reversing order from big to little endian\n);
+ /* If ulDataLength is big endian, assume others are too */
+ /* reverse the byte order for 3 fields */
+ pms-wPINMaxExtraDigit = BSWAP_16(pms-wPINMaxExtraDigit);
+ pms-wLangId = BSWAP_16(pms-wLangId);
+ pms-ulDataLength = BSWAP_32(pms-ulDataLength);
+ }
+ /* At this point we now have the above 3 variables in little endian
Re: [Muscle] Re: pcscd with libusb crashs on Solaris 10
Ludovic Rousseau wrote: 2010/5/10 Douglas E. Engert deeng...@anl.gov: With the new pcsc-lite-1.6.0 and ccid-1.3.13 things are working fine. ccid-1.3.12. version 1.3.13 is not yet available :-) I can not reproduce the failures discribed below. libusb.so.1 has not changed, so I assume some change to pcsc or ccid has fixed the problem! I have not changed libccid to fix this problem. Or at least not intentionally. Could the change have something to do with threads, i.e. using the same thread for all the usb calls for the same reader? Thanks for the notice. Regarding libusb it may be safer/more stable (On Solaris) to use libusb-1.0 and libusb-compat to have the old API instead of libusb-0.1. Solaris man libusb says: The current implementation is version 0.1.8 of the libusb API. I prefer to use what Solaris provides if at all possible. I use this combination on Mac OS X for example. Bye -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] Re: pcscd with libusb crashs on Solaris 10
With the new pcsc-lite-1.6.0 and ccid-1.3.13 things are working fine. I can not reproduce the failures discribed below. libusb.so.1 has not changed, so I assume some change to pcsc or ccid has fixed the problem! On 2/22/2010: Douglas E. Engert wrote: While doing some smartcard testing on Solaris 10 I ran across two bugs with the open source pcsc-lite and ccid code as it interacts with the Solaris libusb. The first fix was accepted by pcsc-lite, but the second was rejected, as a problem with libusb, not pcsc-lite or ccid. I have attached the original messsge with the patches as I know there has been a lot of interest within Sun with using smart cards, Kerberos PKINIT, opensc and pcscd and a number of messages on how to get these to compile on Solaris and Open Solaris. I would hope that someone within Sun would find this interesting and look at it closer to see if it is indeed a bug on libusb or not and if it also fails on Open Solaris. For my testing I can continue to apply the ccid patch. 2010/2/19 Douglas E. Engert deeng...@anl.gov: Two fixes: GCC The gcc on Solaris 10 combined with the Sun loader appears to not handle the gcc visibility attribute correctly. The sparc version says it is ignored, the x86 version gives linker error. The attached patch sun.gcc.1.5.6-svn-477.txt tries to test for gcc on Sun and not use the visibility attribute. If on a sun and the compiler is not GCC, try and use the Sun __global and __hidden instead. (I did not try the Sun Studio compiler with this.) Committed in revision 4766. Thanks PCSCD CRASH pcscd would crash sometimes when a reader was unplugged on Solaris 10 or would not recognize the reader if it was plugged back in. The problem appears to be that once the libusb returns errno == ENODEV no further calls should be made other then to usb_close. The crash is not in pcscd but in libusb on Solaris. libusb should not crash if called on a device that disappeared. libusb should return an error code instead. I reject this patch, sorry. Bye -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pcsc-lite 1.6.0, new major version
Ludovic Rousseau wrote:
Hello,
A new major version of pcsc-lite is now available at [1].
This version includes a lot of new code and changes. But I do not
expect regressions.
I will describe the changes and new features later on my blog [2].
As usual, report any bug. Thanks
While compiling ccid-1.3.11 against pcsc-lite-1.6.0
61 ../../src/src/ifdhandler.c: In function `IFDHControl':
62 ../../src/src/ifdhandler.c:1304: error: structure has no member named
`wLcdMaxCharacters'
63 ../../src/src/ifdhandler.c:1305: error: structure has no member named
`wLcdMaxLines'
64 make[2]: *** [libccid_la-ifdhandler.lo] Error 1
Looks like these are not in the the the PIN_PROPERTIES_STRUCTURE
in 1.6.0 (but was in 1.5.5) in reader.h.in:
209 /** structure used with \ref FEATURE_IFD_PIN_PROPERTIES */
210 typedef struct {
211 uint16_t wLcdLayout; /** display characteristics */
212 uint8_t bEntryValidationCondition;
213 uint8_t bTimeOut2;
214 } PIN_PROPERTIES_STRUCTURE;
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pcsc-lite 1.6.0, new major version
. - Add --enable-embedded (default is no) to build pcsc-lite for an embedded system. This will activate the NO_LOG option to disable logging and limit RAM and disk consumption. - If NO_LOG is defined then no log are displayed. The idea is to limit the binaries size on disk and RAM consumption at execution time. With NO_LOG defined we gain 26% (17 kB) for the .text segment of pcscd and 15% (4 kB) for the .text segment of libpcsclite.so (for i386) - Define a minimal pcsc_stringify_error() if NO_LOG is defined. Only the error code in hex is displayed in this case. Gain: 2kB of .text (10%) for libpcsclite - Add --disable-serial and --disable-usb options --disable-serial removes support of /etc/reader.conf gain: 8.0kB of .text (12%) and 160 bytes of .bss (4%) for pcscd --disable-usb removes support of USB hotplug gain: 9.7kB of .text (14%) and 960 bytes of .bss (23%) for pcscd If you use both options (and use a static driver configuration) gain: 17.7kB of .text (26%) and 1152 bytes of .bss (28%) for pcscd - Better support of Android - some other minor improvements and bug corrections [1] https://alioth.debian.org/frs/?group_id=30105release_id=1506#pcsclite-pcsc-lite-1-6-0-title-content [2] http://ludovicrousseau.blogspot.com/ -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pcsc-lite 1.6.0, new major version
Ludovic Rousseau wrote: 2010/5/5 Douglas E. Engert deeng...@anl.gov: Ludovic Rousseau wrote: Hello, A new major version of pcsc-lite is now available at [1]. This version includes a lot of new code and changes. But I do not expect regressions. I will describe the changes and new features later on my blog [2]. As usual, report any bug. Thanks Changes: pcsc-lite-1.6.0: Ludovic Rousseau 5 May 2010 - redesign the client/server communication: * no more shared memory used (allow pcscd and libpcsclite1.so to be on different computer and talk over a network) Is the protocol compatible with Windows? No. And it is local only. You can't have pcscd and libpcsclite on 2 different systems. Could this then be used with (or added to) the Unix rdesktop http://www.rdesktop.org/ (The Windows Remote Desktop Connection allows sharing a smart card.) rdesktop already uses pcsc-lite and support remote smart card. I see it now, but on the systems I have looked at it was not configured to use it and --help does not show it. I will have to try it out! * no more difference between short and extended APDU * no more use of a /var/run/pcscd/pcscd.events/ directory. events are sent through the socket * simpler command format between client and server The side effect is that you are not able to mix an old pcscd with a new libpcsclite1.so or the reverse. SCardEstablishContext() will fail unless you update both sides of the communication. Does an application have to be recompiled, or can I just replace libpcsclite1.so The API and ABI of libpcsclite.so.1 is the same. So no need to recompile. You just have to upgrade pcscd and libpcsclite at the same time. The only problematic case is if you linked libpcsclite.so _statically_ with your application. But you do not do that, right? Never use static... Bye -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] GDM with smartcard
Todd Denniston wrote: Douglas E. Engert wrote, On 03/12/2010 10:48 AM: Anderson Goulart wrote: Hello, I know this question is on the archives, but I could not find any solution for this yet... I am trying to authenticate a user with a smartcard. I am using OpenSuse 11 with GDM 2.24. Everything is working, but not quite as I would like to. What I am trying to do is deal with insertion and removing the smartcard. When I insert the smartcard I would like GDM to show the PIN dialog without pressing ENTER. And if I remove, GDM should show the Username/Password dialog again. I like this, but PAM today gets in the way. we're talking about URL : ftp://ftp.gnome.org/pub/GNOME/sources/gdm ... the thing you see while you try to log in (also fronts RHEL/CentOS/Fedora boxes), right? Yes and any other vendor's GDM like the Ubuntu (2.28) or Solaris. I don't know what the Solaris version is based on. All of thes can use PAM. But in addition to GDM you will need to look at any screen lock programs, as you will want to unlock with the smart card too. Do the screen lock programs have the same pre-PAM detection of smart cards? for me, gdm has worked in the way Goulart wants: on fedora since circa Fedora 8 on CentOS since at or before CentOS 5.3 the current gdm on CentOS 5 is a heavily patched 2.16.0. the current gdm on Fedora 12 is a patched 2.28.2. There may be other helpers in these distros that I have not looked for. perhaps the patches for smart cards on one of those could be bent to work with the GDM in OpenSuse. Hope this helps. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] GDM with smartcard
Anderson Goulart wrote: Hello, I know this question is on the archives, but I could not find any solution for this yet... I am trying to authenticate a user with a smartcard. I am using OpenSuse 11 with GDM 2.24. Everything is working, but not quite as I would like to. This is how it is: 1) GDM prompts for a Smartcard or a Username. 2) I insert the smartcard 3) Then press ENTER 4) GDM ask for PIN 5) PIN typed and press ENTER again 6) User accepted In addition to GDM, screen unlock applications to use smartcards too. There have been a number of discussions on how PAM should handle smartcards and PINs with the pam_krb5 that can use PKCS#11 with PKINIT. On the kerberos lists and the opensolaris lists. (Consider pin pad readers too.) The main points are PINs are not passwords, and should be treated separately, but PAM is not flexible enough at the present time to do it right. The Russ Albery's open source pam_krb5 will run with GDM and xlock, and use the entry of a blank password to try_pkinit. It can then call the MIT or Heimdal krb5 that will use PKINIT with OpenSC PKCS#11 to authenticate to Kerberos including Windows AD kerberos. What I am trying to do is deal with insertion and removing the smartcard. When I insert the smartcard I would like GDM to show the PIN dialog without pressing ENTER. And if I remove, GDM should show the Username/Password dialog again. I like this, but PAM today gets in the way. The same idea was discussed a few years ago on this list (http://www.mail-archive.com/muscle@lists.musclecard.com/msg04346.html and http://osdir.com/ml/gnome.gdm.general/2006-10/msg00010.html - GDM list) and the solution was not clearly explained for me. Anyone knows how to deal with this? Or have some information that could be useful? I found tw solutions (didn't work) for this: Quest software (http://rc.quest.com/topics/gdm/ - too old) and a multistack patch for GDM 2.28 (Fedora patch), but I could not make it works (in Fedora) and the compilation for Suse 11 was not so easy (because of some newer hal functions). ps: I got an Omnikey card reader Thanks, Global ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] pcscd with libusb crashs on Solaris 10
While doing some smartcard testing on Solaris 10 I ran across two bugs with the open source pcsc-lite and ccid code as it interacts with the Solaris libusb. The first fix was accepted by pcsc-lite, but the second was rejected, as a problem with libusb, not pcsc-lite or ccid. I have attached the original messsge with the patches as I know there has been a lot of interest within Sun with using smart cards, Kerberos PKINIT, opensc and pcscd and a number of messages on how to get these to compile on Solaris and Open Solaris. I would hope that someone within Sun would find this interesting and look at it closer to see if it is indeed a bug on libusb or not and if it also fails on Open Solaris. For my testing I can continue to apply the ccid patch. 2010/2/19 Douglas E. Engert deeng...@anl.gov: Two fixes: GCC The gcc on Solaris 10 combined with the Sun loader appears to not handle the gcc visibility attribute correctly. The sparc version says it is ignored, the x86 version gives linker error. The attached patch sun.gcc.1.5.6-svn-477.txt tries to test for gcc on Sun and not use the visibility attribute. If on a sun and the compiler is not GCC, try and use the Sun __global and __hidden instead. (I did not try the Sun Studio compiler with this.) Committed in revision 4766. Thanks PCSCD CRASH pcscd would crash sometimes when a reader was unplugged on Solaris 10 or would not recognize the reader if it was plugged back in. The problem appears to be that once the libusb returns errno == ENODEV no further calls should be made other then to usb_close. The crash is not in pcscd but in libusb on Solaris. libusb should not crash if called on a device that disappeared. libusb should return an error code instead. I reject this patch, sorry. Bye -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ---BeginMessage--- Two fixes: GCC The gcc on Solaris 10 combined with the Sun loader appears to not handle the gcc visibility attribute correctly. The sparc version says it is ignored, the x86 version gives linker error. The attached patch sun.gcc.1.5.6-svn-477.txt tries to test for gcc on Sun and not use the visibility attribute. If on a sun and the compiler is not GCC, try and use the Sun __global and __hidden instead. (I did not try the Sun Studio compiler with this.) PCSCD CRASH pcscd would crash sometimes when a reader was unplugged on Solaris 10 or would not recognize the reader if it was plugged back in. The problem appears to be that once the libusb returns errno == ENODEV no further calls should be made other then to usb_close. The attached patch enodev.1.43.11-svn-4750.txt in ccid_usb.c defines errno_enodev for each reader. If any of the usb_* calls return ENODEV errno_enodev will be set. Any further read, write or control operations to the device will not be attempted. The ifdhandler.c was also modified to remove the CmdPowerOff call, since this can be called via HPRemoveHotPlugable-RFRemoveReader- RFUninitializingReader-IFDCloseIFD-(ccid)IFDCloseChannel This path leads to trying to power off a reader that is not present, and can cause a crash. There is comment in RFUninitializeReader /* * If the reader is getting uninitialized then it is being unplugged * so I can't send a IFDPowerICC call to it * * IFDPowerICC( rContext, IFD_POWER_DOWN, Atr, AtrLen ); */ If it was not a good idea to call IFDPowerICC here, it is not a good idea to call it from IFDCloseChannel either. i.e. if the hotplug_libusb.c says the reader is not there, no operations should be attempted. (There may be some other code path where IFDCloseIFD should call IFDPowerICC, but I did not see that. I also did not see and easy way set the errno_enodev to avoid this call either.) With these changes I can plug and unplug readers, without a crash, and with out losing the reader. I may have missed something, but it looks like these changes should work for any OS. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 --- ./src/,misc.h Wed Nov 18 10:32:33 2009 +++ ./src/misc.hTue Feb 16 15:42:19 2010 @@ -24,9 +24,13 @@ * see http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Function-Attributes.html#Function-Attributes * see http://www.nedprod.com/programs/gccvisibility.html */ -#if defined __GNUC__ (__GNUC__ = 4 || (__GNUC__ == 3 __GNUC_MINOR__ = 3)) +#if defined __GNUC__ (! defined (__sun)) (__GNUC__ = 4 || (__GNUC__ == 3 __GNUC_MINOR__ = 3)) #define INTERNAL __attribute__ ((visibility(hidden))) #define PCSC_API __attribute__ ((visibility(default))) +#elif (! defined __GNUC__ ) defined (__sun) +/* http://wikis.sun.com/display/SunStudio/Macros+for+Shared+Library+Symbol+Visibility */ +#define INTERNAL __hidden +#define PCSC_API __global #else #define INTERNAL #define PCSC_API --- ./src
Re: [Muscle] new BETA versions of pcsc-lite and libccid
Two fixes:
GCC
The gcc on Solaris 10 combined with the Sun loader appears to not handle
the gcc visibility attribute correctly. The sparc version says it is
ignored, the x86 version gives linker error. The attached patch
sun.gcc.1.5.6-svn-477.txt tries to test for gcc on Sun and not use
the visibility attribute. If on a sun and the compiler is not GCC,
try and use the Sun __global and __hidden instead. (I did not try the Sun
Studio compiler with this.)
PCSCD CRASH
pcscd would crash sometimes when a reader was unplugged on Solaris 10
or would not recognize the reader if it was plugged back in. The problem
appears to be that once the libusb returns errno == ENODEV no further
calls should be made other then to usb_close.
The attached patch enodev.1.43.11-svn-4750.txt in ccid_usb.c defines
errno_enodev for each reader. If any of the usb_* calls return ENODEV
errno_enodev will be set. Any further read, write or control operations
to the device will not be attempted.
The ifdhandler.c was also modified to remove the CmdPowerOff call, since
this can be called via HPRemoveHotPlugable-RFRemoveReader-
RFUninitializingReader-IFDCloseIFD-(ccid)IFDCloseChannel
This path leads to trying to power off a reader that is not present,
and can cause a crash.
There is comment in RFUninitializeReader
/*
* If the reader is getting uninitialized then it is being unplugged
* so I can't send a IFDPowerICC call to it
*
* IFDPowerICC( rContext, IFD_POWER_DOWN, Atr, AtrLen );
*/
If it was not a good idea to call IFDPowerICC here, it is not a
good idea to call it from IFDCloseChannel either. i.e. if the
hotplug_libusb.c says the reader is not there, no operations should be
attempted. (There may be some other code path where IFDCloseIFD
should call IFDPowerICC, but I did not see that. I also did not see
and easy way set the errno_enodev to avoid this call either.)
With these changes I can plug and unplug readers, without a crash,
and with out losing the reader.
I may have missed something, but it looks like these changes should
work for any OS.
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--- ./src/,misc.h Wed Nov 18 10:32:33 2009
+++ ./src/misc.hTue Feb 16 15:42:19 2010
@@ -24,9 +24,13 @@
* see
http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Function-Attributes.html#Function-Attributes
* see http://www.nedprod.com/programs/gccvisibility.html
*/
-#if defined __GNUC__ (__GNUC__ = 4 || (__GNUC__ == 3 __GNUC_MINOR__ =
3))
+#if defined __GNUC__ (! defined (__sun)) (__GNUC__ = 4 || (__GNUC__ ==
3 __GNUC_MINOR__ = 3))
#define INTERNAL __attribute__ ((visibility(hidden)))
#define PCSC_API __attribute__ ((visibility(default)))
+#elif (! defined __GNUC__ ) defined (__sun)
+/*
http://wikis.sun.com/display/SunStudio/Macros+for+Shared+Library+Symbol+Visibility
*/
+#define INTERNAL __hidden
+#define PCSC_API __global
#else
#define INTERNAL
#define PCSC_API
--- ./src/,ccid_usb.c Tue Feb 9 15:31:38 2010
+++ ./src/ccid_usb.cFri Feb 19 11:12:00 2010
@@ -62,6 +62,7 @@
char *dirname;
char *filename;
int interface;
+ int errno_enodev;
/*
* Endpoints
@@ -524,6 +525,7 @@
usbDevice[reader_index].handle =
dev_handle;
usbDevice[reader_index].dirname =
strdup(bus-dirname);
usbDevice[reader_index].filename =
strdup(dev-filename);
+ usbDevice[reader_index].errno_enodev =
0;
usbDevice[reader_index].interface =
interface;
usbDevice[reader_index].real_nb_opened_slots = 1;
usbDevice[reader_index].nb_opened_slots
= usbDevice[reader_index].real_nb_opened_slots;
@@ -584,6 +586,13 @@
DEBUG_XXD(debug_header, buffer, length);
+ /* If we previously received errno == ENODEV return failed */
+ if (usbDevice[reader_index].errno_enodev == 1)
+ {
+ DEBUG_CRITICAL(WriteUSB errno_enodev == 1 %d);
+ return STATUS_NO_SUCH_DEVICE;
+ }
+
rv = usb_bulk_write(usbDevice[reader_index].handle,
usbDevice[reader_index].bulk_out, (char *)buffer, length,
USB_WRITE_TIMEOUT);
@@ -595,7 +604,11 @@
usb_strerror());
if (ENODEV == errno)
+ {
+ usbDevice[reader_index].errno_enodev = 1;
+ DEBUG_CRITICAL(usb_bulk_write errno == ENODEV);
return STATUS_NO_SUCH_DEVICE;
+ }
return STATUS_UNSUCCESSFUL;
}
@@ -621,6 +634,13 @@
(void)snprintf(debug_header, sizeof(debug_header), - %06X ,
(int)reader_index
Re: [Muscle] new BETA versions of pcsc-lite and libccid
Here are some other interesting points on pcsc and gcc on Solaris 10. I have been able to compile with gcc on Sparc, but on an i386 system, I get the same type of failures Kevin has reported. The issue appears to be in misc.h in the use of the gcc __attribute__ #define INTERNAL __attribute__ ((visibility(hidden))) If I use the attached patch, to misc.h to not use this. pcsc now compiles on both sparc and i386 using Suns /usr/sfw/bin/gcc. This would also explain why the Sun Studio cc works, as it does not use the INTERNAL either. Without the patch: On sparc Solaris 10, this the attribute is ignored with many warnings like: ../../src/src/sys_unix.c:403: warning: visibility attribute not supported in this configuration; ignored ../../src/src/sys_unix.c: In function `SYS_GetSeed': But on i386, they are not ignored, but then the link has problems like this: libtool: link: gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,libpcsclite.so.1 -o .libs/libpcsclite.so.1.0.0 .libs/libpcsclite_la-debug.o .libs/libpcsclite_la-dyn_hpux.o .libs/libpcsclite_la-dyn_macosx.o .libs/libpcsclite_la-dyn_unix.o .libs/libpcsclite_la-error.o .libs/libpcsclite_la-winscard_clnt.o .libs/libpcsclite_la-strlcat.o .libs/libpcsclite_la-strlcpy.o .libs/libpcsclite_la-sys_unix.o .libs/libpcsclite_la-thread_unix.o .libs/libpcsclite_la-utils.o .libs/libpcsclite_la-winscard_msg.o -R/opt/smartcard/lib:/usr/sfw/lib -R/usr/local/lib -L/usr/local/lib -ldl -lsocket -lc -pthreads -pthreads -pthreads Text relocation remains referenced against symbol offset in file SYS_CloseFile 0x5b7 .libs/libpcsclite_la-sys_unix.o SYS_CloseFile 0x608 .libs/libpcsclite_la-sys_unix.o SYS_CloseFile 0x659 .libs/libpcsclite_la-sys_unix.o SHMMessageSend 0x858 .libs/libpcsclite_la-winscard_msg.o SHMMessageSend 0x8ae .libs/libpcsclite_la-winscard_msg.o SHMMessageSend 0x8f0 .libs/libpcsclite_la-winscard_msg.o SYS_Chdir 0x6b5 .libs/libpcsclite_la-sys_unix.o SYS_Fork0x4d1 .libs/libpcsclite_la-sys_unix.o SYS_Fork0x540 .libs/libpcsclite_la-sys_unix.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make[2]: *** [libpcsclite.la] Error 1 % gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Copyright (C) 2004 Free Software Foundation, Inc. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 --- ,misc.h Fri May 9 09:59:08 2008 +++ misc.h Mon Feb 15 10:38:31 2010 @@ -24,7 +24,7 @@ * see http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Function-Attributes.html#Function-Attributes * see http://www.nedprod.com/programs/gccvisibility.html */ -#if defined __GNUC__ (__GNUC__ = 4 || (__GNUC__ == 3 __GNUC_MINOR__ = 3)) +#if defined __GNUC__ (! defined (__sun)) (__GNUC__ = 4 || (__GNUC__ == 3 __GNUC_MINOR__ = 3)) #define INTERNAL __attribute__ ((visibility(hidden))) #define PCSC_API __attribute__ ((visibility(default))) #else ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] new BETA versions of pcsc-lite and libccid
Kevin Reinholz wrote: On 2/12/10 7:16 AM, Douglas E. Engert wrote: Ludovic Rousseau wrote: 2010/2/11 Douglas E. Engert deeng...@anl.gov: Replying to my own message, I did some more tests with 1.5.5 and ccid-1.3.11 and can get a bus error with these also. I then did: reboot with reader present. Start pcscd -d -f unplugged reader plugged it back in insert card Got message about IFDHPowerICC() PowerUp failed So reinserted the card. run pkcs15-tool -r pulled out card inserted card pulled out card unplugged reader got bus error. So the bus error is not related to latest mods. but still present. I rebuild pcsc-lite using hotplug_libusb and I also have crashes if I use electric-fence. I don't think I have them if I use hotplug_libhal, but I will double check. Maybe the bug is in hotplug_libusb. I am still looking too. Solaris does not have hal, so have to use libusb. For what it's worth, OpenSolaris (SunOS 5.11) does have HAL now so that might be an interesting thing to test. I've built pcsc-lite-1.5.5 and ccid-1.3.11 using Sun Studio 12 on SunOS 5.11 as GCC choked on pcsc-lite under that platform. Interesting, I have not had issues with gcc from Sun on Solaris 10. %/usr/sfw/bin/gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. But I used the disable-hal and enable-usb flags when I did it. Do you have any problems when removing a reader? It turns out 1.5.5 has problems when removing a reader. I also noted that I could remove the reader sometimes, but If I reinserted it in the same spot, pcscd would not see it. If I put it into a different spot, usb/pcscd would see it as a new reader /n in the name would change. I can try compiling these new betas on SunOS 5.11 and see what happens. Thanks for the report. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] new BETA versions of pcsc-lite and libccid
Ludovic Rousseau wrote: 2010/2/10 Douglas E. Engert deeng...@anl.gov: Ludovic Rousseau wrote: Hello, I uploaded to [1] new versions of pcsc-lite and libccid. They have many and important changes (in particular for pcsc-lite). I would like to test these versions before I release them as stable. They work for me and should work for you too. On Solaris 10 using Sun's libucb, I am getting intermittent core dumps. The #2 output attached is from starting pcscd -f -d with a GemPC twin reader, and inserting a card, removing it and inserting again. The #1 output was after pcsc15-tool -r read a certificate correctly, then when going to remove the card, got a core dump. According to the logs the reader disapeared from the USB bus. And pcscd removed it from its list. But you do not indicate you removed the reader. Is that exact? That is correct. But as a test, I started pcscd with the reader plugged in, then unplug the reader, I get a Bus Error. See: pcsc-svn.error.3.txt So powered down the machine, to make sure any hardware was reset, booted, and tried running the pcscd-1.5.5 and ccid-1.3.11. No problems pulling the reader. See pcsc-1.5.5.ok.3.txt Then tried the pcscd-1.5.6-svn... and ccid-1.3.11-svn... I then did: unplugged reader plugged it back in insert card run pkcs15-tool -r pulled out card inserted card pulled out card unplugged reader got bus error. see pcsc-svn.error.4.txt Further attempts after starting pcscd then unplugging the reader got bus errors. So it is not clear if something is leaving the Solaris usb code in a strange state? Then the crash happens in a libusb call. #6 0xff382ca4 in usb_find_devices () from /usr/sfw/lib/libusb.so.1 I would suspect a bug in the USB layer. pcsc-lite-1.5.5 and ccid-1.3.11 work fine (pcsc-1.5.5 does have this patch which appears to be in 1.5.6-snv-4744) --- ./src/,pcscdaemon.c Sat Jul 4 03:10:31 2009 +++ ./src/pcscdaemon.c Mon Aug 31 16:18:18 2009 @@ -576,6 +576,8 @@ return; HPReCheckSerialReaders(); + + (void)signal(SIGUSR1, signal_reload); } /* signal_reload */ static void signal_trap(/*...@unused@*/ int sig) This was added in revision 4375 http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2009-September/003893.html pkcs15-tool is reading a certificate... 0067 ../../src/src/ifdhandler.c:1219:IFDHTransmitToICC() usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 00050829 ../../src/src/winscard_svc.c:290:ContextThread() Received command: TRANSMIT from client 10 0127 ../../src/src/winscard.c:1660:SCardTransmit() Send Protocol: T=1 0068 ../../src/src/ifdhandler.c:1219:IFDHTransmitToICC() usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 00045231 ../../src/src/winscard_svc.c:290:ContextThread() Received command: TRANSMIT from client 10 0120 ../../src/src/winscard.c:1660:SCardTransmit() Send Protocol: T=1 0070 ../../src/src/ifdhandler.c:1219:IFDHTransmitToICC() usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 00053094 ../../src/src/winscard_svc.c:290:ContextThread() Received command: END_TRANSACTION from client 10 0109 ../../src/src/winscard.c:1193:SCardEndTransaction() Status: 0x 00010371 ../../src/src/winscard_svc.c:290:ContextThread() Received command: DISCONNECT from client 10 0103 ../../src/src/winscard.c:866:SCardDisconnect() Active Contexts: 1 0673 ../../src/src/ifdhandler.c:1090:IFDHPowerICC() action: Reset, usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 00286468 ../../src/src/winscard.c:927:SCardDisconnect() Reset complete. 0391 ../../src/src/winscard_svc.c:290:ContextThread() Received command: RELEASE_CONTEXT from client 10 0086 ../../src/src/winscard.c:228:SCardReleaseContext() Releasing Context: 0x1033911 2782 ../../src/src/winscard_svc.c:284:ContextThread() Client die: 10 0162 ../../src/src/winscard_svc.c:921:MSGCleanupClient() Thread is stopping: dwClientID=10, threadContext @548B0 0071 ../../src/src/winscard_svc.c:927:MSGCleanupClient() Freeing SCONTEXT @548B0 08517173 ../../src/src/ccid_usb.c:595:WriteUSB() usb_bulk_write(/dev/usb/8e6.3437/0): No such device Your device disapeared here. Have you removed it? No. 0143 ../../src/src/ifdwrapper.c:471:IFDStatusICC() Card not transacted: 617 0204 ../../src/src/utils.c:66:SendHotplugSignal() Send hotplug signal to pcscd (pid=10619) 0166 ../../src/src/eventhandler.c:378:EHStatusHandlerThread() Error communicating to: Gemplus GemPC Twin 00 00 00112336 ../../src/src/hotplug_libusb.c:557:HPRemoveHotPluggable() Removing USB device[0]: /dev/usb:8e6.3437/0 0132 ../../src/src/eventhandler.c:170:EHDestroyEventHandler() Stomping thread. 0086 ../../src/src/ifdhandler.c:365:IFDHGetCapabilities() tag: 0xFB1, usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 0079 ../../src/src/eventhandler.c:183:EHDestroyEventHandler() Waiting polling thread 00287507 ../../src/src/eventhandler.c:519:EHStatusHandlerThread() Die 0233 ../../src/src/eventhandler.c:207
Re: [Muscle] new BETA versions of pcsc-lite and libccid
Replying to my own message, I did some more tests with 1.5.5 and ccid-1.3.11 and can get a bus error with these also. I then did: reboot with reader present. Start pcscd -d -f unplugged reader plugged it back in insert card Got message about IFDHPowerICC() PowerUp failed So reinserted the card. run pkcs15-tool -r pulled out card inserted card pulled out card unplugged reader got bus error. So the bus error is not related to latest mods. but still present. Douglas E. Engert wrote: Ludovic Rousseau wrote: 2010/2/10 Douglas E. Engert deeng...@anl.gov: Ludovic Rousseau wrote: Hello, I uploaded to [1] new versions of pcsc-lite and libccid. They have many and important changes (in particular for pcsc-lite). I would like to test these versions before I release them as stable. They work for me and should work for you too. On Solaris 10 using Sun's libucb, I am getting intermittent core dumps. The #2 output attached is from starting pcscd -f -d with a GemPC twin reader, and inserting a card, removing it and inserting again. The #1 output was after pcsc15-tool -r read a certificate correctly, then when going to remove the card, got a core dump. According to the logs the reader disapeared from the USB bus. And pcscd removed it from its list. But you do not indicate you removed the reader. Is that exact? That is correct. But as a test, I started pcscd with the reader plugged in, then unplug the reader, I get a Bus Error. See: pcsc-svn.error.3.txt So powered down the machine, to make sure any hardware was reset, booted, and tried running the pcscd-1.5.5 and ccid-1.3.11. No problems pulling the reader. See pcsc-1.5.5.ok.3.txt Then tried the pcscd-1.5.6-svn... and ccid-1.3.11-svn... I then did: unplugged reader plugged it back in insert card run pkcs15-tool -r pulled out card inserted card pulled out card unplugged reader got bus error. see pcsc-svn.error.4.txt Further attempts after starting pcscd then unplugging the reader got bus errors. So it is not clear if something is leaving the Solaris usb code in a strange state? Then the crash happens in a libusb call. #6 0xff382ca4 in usb_find_devices () from /usr/sfw/lib/libusb.so.1 I would suspect a bug in the USB layer. pcsc-lite-1.5.5 and ccid-1.3.11 work fine (pcsc-1.5.5 does have this patch which appears to be in 1.5.6-snv-4744) --- ./src/,pcscdaemon.c Sat Jul 4 03:10:31 2009 +++ ./src/pcscdaemon.c Mon Aug 31 16:18:18 2009 @@ -576,6 +576,8 @@ return; HPReCheckSerialReaders(); + + (void)signal(SIGUSR1, signal_reload); } /* signal_reload */ static void signal_trap(/*...@unused@*/ int sig) This was added in revision 4375 http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2009-September/003893.html pkcs15-tool is reading a certificate... 0067 ../../src/src/ifdhandler.c:1219:IFDHTransmitToICC() usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 00050829 ../../src/src/winscard_svc.c:290:ContextThread() Received command: TRANSMIT from client 10 0127 ../../src/src/winscard.c:1660:SCardTransmit() Send Protocol: T=1 0068 ../../src/src/ifdhandler.c:1219:IFDHTransmitToICC() usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 00045231 ../../src/src/winscard_svc.c:290:ContextThread() Received command: TRANSMIT from client 10 0120 ../../src/src/winscard.c:1660:SCardTransmit() Send Protocol: T=1 0070 ../../src/src/ifdhandler.c:1219:IFDHTransmitToICC() usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 00053094 ../../src/src/winscard_svc.c:290:ContextThread() Received command: END_TRANSACTION from client 10 0109 ../../src/src/winscard.c:1193:SCardEndTransaction() Status: 0x 00010371 ../../src/src/winscard_svc.c:290:ContextThread() Received command: DISCONNECT from client 10 0103 ../../src/src/winscard.c:866:SCardDisconnect() Active Contexts: 1 0673 ../../src/src/ifdhandler.c:1090:IFDHPowerICC() action: Reset, usb:08e6/3437:libusb:/dev/usb:8e6.3437/0 (lun: 0) 00286468 ../../src/src/winscard.c:927:SCardDisconnect() Reset complete. 0391 ../../src/src/winscard_svc.c:290:ContextThread() Received command: RELEASE_CONTEXT from client 10 0086 ../../src/src/winscard.c:228:SCardReleaseContext() Releasing Context: 0x1033911 2782 ../../src/src/winscard_svc.c:284:ContextThread() Client die: 10 0162 ../../src/src/winscard_svc.c:921:MSGCleanupClient() Thread is stopping: dwClientID=10, threadContext @548B0 0071 ../../src/src/winscard_svc.c:927:MSGCleanupClient() Freeing SCONTEXT @548B0 08517173 ../../src/src/ccid_usb.c:595:WriteUSB() usb_bulk_write(/dev/usb/8e6.3437/0): No such device Your device disapeared here. Have you removed it? No. 0143 ../../src/src/ifdwrapper.c:471:IFDStatusICC() Card not transacted: 617 0204 ../../src/src/utils.c:66:SendHotplugSignal() Send hotplug signal to pcscd (pid=10619) 0166 ../../src/src/eventhandler.c:378:EHStatusHandlerThread() Error communicating to: Gemplus GemPC Twin
Re: [Muscle] new BETA versions of pcsc-lite and libccid
Ludovic Rousseau wrote: 2010/2/11 Douglas E. Engert deeng...@anl.gov: Replying to my own message, I did some more tests with 1.5.5 and ccid-1.3.11 and can get a bus error with these also. I then did: reboot with reader present. Start pcscd -d -f unplugged reader plugged it back in insert card Got message about IFDHPowerICC() PowerUp failed So reinserted the card. run pkcs15-tool -r pulled out card inserted card pulled out card unplugged reader got bus error. So the bus error is not related to latest mods. but still present. I rebuild pcsc-lite using hotplug_libusb and I also have crashes if I use electric-fence. I don't think I have them if I use hotplug_libhal, but I will double check. Maybe the bug is in hotplug_libusb. I am still looking too. Solaris does not have hal, so have to use libusb. Thanks for the report. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Re: new (beta) version of pcsc-lite 1.5.6-svn-4527
Ludovic Rousseau wrote:
Hello,
I updated the online version to svn-4527 with an important bug correction.
But since I got no feedback from my previous announce I guess no one
ever tried to build or use these beta versions. Bad news :-(
You should report bugs _now_.
On Solaris 10, AF_LOCAL is not defined, but AF_UNIX is.
See attached patch.
With the above it runs using the Solaris /usr/sfw/bin/gcc
and the /usr/sfw/lib/libusb:
PC/SC lite has been configured with following options:
Version: 1.5.5
System binaries: /opt/smartcard/sbin
Configuration files: /opt/smartcard/etc
Host:sparc-sun-solaris2.10
Compiler:gcc
Preprocessor flags: -I${top_srcdir}/src -DDEBUG -I/include -D_TS_ERRNO
-I/usr/local/include
Compiler flags: -Wall -fno-common -g
Preprocessor flags: -I${top_srcdir}/src -DDEBUG -I/include -D_TS_ERRNO
-I/usr/local/include
Linker flags:-g -R/opt/smartcard/lib,/usr/sfw/lib -L/lib
-L/usr/local/lib -R/usr/local/lib
Libraries:-lsocket
PTHREAD_CFLAGS: -D_REENTRANT -pthreads
PTHREAD_LIBS:
PCSC_ARCH: Solaris
libhal support: no
libusb support: yes
USB drop directory: /opt/smartcard/pcsc/drivers
ATR parsing messages: false
confdir: /etc
ipcdir: /var/run/pcscd
Bye
2009/10/21 Ludovic Rousseau ludovic.rouss...@gmail.com:
Hello,
I worked on the internals of pcsc-lite. I changed the way libpcsclite
and pcscd are communicating:
- no more use of a shared memory segment
- no more distinction between short and extended APDU
- and some other improvements
I would like to have beta testers of this version. I only tested it on
GNU/Linux (and recompiled it on Mac OS X). I would like to have
reports from Solaris and *BSD users in particular.
The source code is available at [1].
Thanks
[1] http://ludovic.rousseau.free.fr/softwares/pcsc-lite/
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Index: src/winscard_msg.c
===
--- src/winscard_msg.c (revision 4529)
+++ src/winscard_msg.c (working copy)
@@ -62,6 +62,9 @@
int one;
int ret;
+#ifndef AF_LOCAL
+#define AF_LOCAL AF_UNIX
+#endif
ret = socket(AF_LOCAL, SOCK_STREAM, 0);
if (ret 0)
{
Index: src/winscard_msg_srv.c
===
--- src/winscard_msg_srv.c (revision 4529)
+++ src/winscard_msg_srv.c (working copy)
@@ -102,6 +102,10 @@
/*
* Create the common shared connection socket
*/
+#ifndef AF_LOCAL
+#define AF_LOCAL AF_UNIX
+#endif
+
if ((commonSocket = socket(AF_LOCAL, SOCK_STREAM, 0)) 0)
{
Log2(PCSC_LOG_CRITICAL, Unable to create common socket: %s,
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] new version of pcsc-lite 1.5.5
pcscdeamon.c sets up a signal handler for SIGUSR1 to call signal_reload. But on Solaris (at least and it looks like HP too) the man pages say: If signal()is used, disp is the address of a signal handler, and sig is not SIGILL, SIGTRAP, or SIGPWR, the system first sets the signal's disposition to SIG_DFL before executing the signal handler. Thus the first use of pcscd -H works, but the second time causes the deamon to not cache the signal and end. This looks like this has been in previous versions as well. The patch has the signal handler reenable the signal. Use of sigaction might be a better solution. Ludovic Rousseau wrote: Hello, A new version of pcsc-lite 1.5.5 is available at [1]. This version fixes bugs. No new feature added. Changelog: pcsc-lite-1.5.5: Ludovic Rousseau 28 July 2009 - add the reader interface name if provided by the device - SCardTransmit(): return SCARD_E_UNSUPPORTED_FEATURE if SCARD_PROTOCOL_RAW is requested by unsupported - SCardConnect() and SCardReconnect(): set dwActiveProtocol to SCARD_PROTOCOL_UNDEFINED if SCARD_SHARE_DIRECT is used (conform to MSDN). Contrary to Windows winscard behavior, the reader is accessed in shared mode and not exclusive mode if SCARD_SHARE_DIRECT is used. - SCardControl(): correctly check for buffer overflow (bug introduced in pcsc-lite 1.5.4) - some other minor improvements and bug corrections [1] https://alioth.debian.org/frs/?group_id=30105release_id=1378 -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 --- ./src/,pcscdaemon.c Sat Jul 4 03:10:31 2009 +++ ./src/pcscdaemon.c Mon Aug 31 16:18:18 2009 @@ -576,6 +576,8 @@ return; HPReCheckSerialReaders(); + + (void)signal(SIGUSR1, signal_reload); } /* signal_reload */ static void signal_trap(/*...@unused@*/ int sig) ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Fly Clear - Registered Traveler smartcard
Nick D wrote: So I have one of these smart cards and started just fooling around with it. It looks to be a Oberthur CS PIV End Point v1.08 FIPS201 Certified smartcard. Looking at their webpage they do indeed make the registered traveler card. Fly Clear card: ATR: 3b db 96 00 81 b1 fe 45 1f 03 80 f9 a0 00 00 03 48 00 00 00 01 49 Oberthur PIV : ATR: 3B DB 96 00 81 B1 FE 45 1F 03 80 F9 A0 00 00 03 08 00 00 10 00 18 The regular PIV drivers fails to read the card properly however some google searching found a Solaris smart card reader application configuration file for this exact card here: PIV is actually an application on a card. And there are 4 card vendors including Obether, with an approved PIV application listed on: http://fips201ep.cio.gov/apl.php Obether may be using the same card but with a different application. The PIV application will respond to the SELECT command as defined in section 3.1.1 of: http://csrc.nist.gov/publications/nistpubs/800-73-2/sp800-73-2_part2_end-point-piv-card-application-card-command-interface-final.pdf and in Section 2.2 of: http://csrc.nist.gov/publications/nistpubs/800-73-2/sp800-73-2_part1-datamodel-final.pdf i.e. send: Outgoing APDU data [ 15 bytes] = 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 ... == and receive something like: Incoming APDU data [ 96 bytes] = 61 5C 4F 0B A0 00 00 03 08 00 00 10 00 01 00 79 a\Oy 07 4F 05 A0 00 00 03 08 50 27 50 65 72 73 6F 6E .O..P'Person 61 6C 5F 49 64 65 6E 74 69 74 79 5F 61 6E 64 5F al_Identity_and_ 56 65 72 69 66 69 63 61 74 69 6F 6E 5F 43 61 72 Verification_Car 64 5F 50 1A 68 74 74 70 3A 2F 2F 63 73 72 63 2E d_P.http://csrc. 6E 69 73 74 2E 67 6F 76 2F 6E 70 69 76 70 90 00 nist.gov/npivp.. == If the card does not respond with the application ID, then it is not PIV. http://blogs.sun.com/ThinkThin/resource/7dec2008-thinkthin-OberthurCS.cfg Using the APDU commands within this config file I managed to get something out of the card: opensc-tool --send-apdu 00A4040007A00151 Sending: 00 A4 04 00 07 A0 00 00 01 51 00 00 Received (SW1=0x90, SW2=0x00): 6F 6D 84 07 A0 00 00 01 51 00 00 A5 62 73 2F 06 om..Q...bs/. 07 2A 86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 .*.H..k.`...*.H. FC 6B 02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B .kc...*.H..k 03 64 0B 06 09 2A 86 48 86 FC 6B 04 01 05 9F 6E .d...*.H..kn 2A 20 50 50 00 40 41 40 91 00 5F 72 52 98 00 08 * p...@a@.._rR... 34 98 00 11 42 80 04 11 43 80 04 11 44 80 04 13 4...B...C...D... 02 00 00 11 45 80 52 18 10 00 00 9F 65 01 FFE.R.e.. Seems kind of interesting. Not sure anything can be done with this card. Figured I would share my findings and maybe hear what others have to say. - Nick -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Fly Clear - Registered Traveler smartcard
Peter Tomlinson wrote: I have heard from someone at NIST that there are FIPS-201 schemes and schemes that are not fully FIPS-201 compliant... Maybe so, but its not a PIV application on the card. Oberthur is using their card for some other application, which may have nothing to do with FIPS-201. Peter Nick D wrote: Yeah I suspected it was a different application: Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 Received (SW1=0x6A, SW2=0x82) Would be kind of neat to see what was going on with the card. - Nick On Tue, Feb 03, 2009 at 10:37:26AM -0600, Douglas E. Engert wrote: Nick D wrote: So I have one of these smart cards and started just fooling around with it. It looks to be a Oberthur CS PIV End Point v1.08 FIPS201 Certified smartcard. Looking at their webpage they do indeed make the registered traveler card. Fly Clear card: ATR: 3b db 96 00 81 b1 fe 45 1f 03 80 f9 a0 00 00 03 48 00 00 00 01 49 Oberthur PIV : ATR: 3B DB 96 00 81 B1 FE 45 1F 03 80 F9 A0 00 00 03 08 00 00 10 00 18 The regular PIV drivers fails to read the card properly however some google searching found a Solaris smart card reader application configuration file for this exact card here: PIV is actually an application on a card. And there are 4 card vendors including Obether, with an approved PIV application listed on: http://fips201ep.cio.gov/apl.php Obether may be using the same card but with a different application. The PIV application will respond to the SELECT command as defined in section 3.1.1 of: http://csrc.nist.gov/publications/nistpubs/800-73-2/sp800-73-2_part2_end-point-piv-card-application-card-command-interface-final.pdf and in Section 2.2 of: http://csrc.nist.gov/publications/nistpubs/800-73-2/sp800-73-2_part1-datamodel-final.pdf i.e. send: Outgoing APDU data [ 15 bytes] = 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 ... == and receive something like: Incoming APDU data [ 96 bytes] = 61 5C 4F 0B A0 00 00 03 08 00 00 10 00 01 00 79 a\Oy 07 4F 05 A0 00 00 03 08 50 27 50 65 72 73 6F 6E .O..P'Person 61 6C 5F 49 64 65 6E 74 69 74 79 5F 61 6E 64 5F al_Identity_and_ 56 65 72 69 66 69 63 61 74 69 6F 6E 5F 43 61 72 Verification_Car 64 5F 50 1A 68 74 74 70 3A 2F 2F 63 73 72 63 2E d_P.http://csrc. 6E 69 73 74 2E 67 6F 76 2F 6E 70 69 76 70 90 00 nist.gov/npivp.. == If the card does not respond with the application ID, then it is not PIV. http://blogs.sun.com/ThinkThin/resource/7dec2008-thinkthin-OberthurCS.cfg Using the APDU commands within this config file I managed to get something out of the card: opensc-tool --send-apdu 00A4040007A00151 Sending: 00 A4 04 00 07 A0 00 00 01 51 00 00 Received (SW1=0x90, SW2=0x00): 6F 6D 84 07 A0 00 00 01 51 00 00 A5 62 73 2F 06 om..Q...bs/. 07 2A 86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 .*.H..k.`...*.H. FC 6B 02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B .kc...*.H..k 03 64 0B 06 09 2A 86 48 86 FC 6B 04 01 05 9F 6E .d...*.H..kn 2A 20 50 50 00 40 41 40 91 00 5F 72 52 98 00 08 * p...@a@.._rR... 34 98 00 11 42 80 04 11 43 80 04 11 44 80 04 13 4...B...C...D... 02 00 00 11 45 80 52 18 10 00 00 9F 65 01 FFE.R.e.. Seems kind of interesting. Not sure anything can be done with this card. Figured I would share my findings and maybe hear what others have to say. - Nick -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] How can I know what's the type of a card through it's ATR?
Lion, Within the many messages of this thread, you appear to have only one unknown smart card to test which people on the list have identified for you as appears a pay-tv card. But what are your motives: If you are you trying to learn about smartcards, buy a modern supported card or cards to play with. If you are developing TV set top box to use the card, contact the card vendor for more information on the card and ask how you can work with them. If your intent is to try and circumvent the security of the card in order to get free TV, quite wasting the time of the people on this mailing list. lion wrote: http://www.nagravision.com/ It should be a pay-tv card. One of the more secret cards. I don't think you can do anything with this card (except watch TV). In general, the game is to create faked pay-tv cards not try to use a real one. Yes, that's right. It's used in our set-top box(STB). I just try to do some base firmware tests now. And may be added supports under OpenCT later. I changed a card and readed out the ATR: TS: 3f T0: ff TA1:95 TB1:00 TC1: ff TD1: 91 TA2: 81 TD2:71 TA3:a0 TB3:47 TC3:00 History: 44 4e 415350 30 20 54 65 73 74 30 33 So, It should be a nagravision card , and there may be some unknow problems in the former card i used. But I got a new problem. The TD1 in the ATR is 0x91, so only protocol T=1 is supported. And TA1 is 0x95, that means Fi=9, Di=5,not Fd=Dd=1 any more. And TA2 is 0x81, means that it's Specific mode.and it's bit5=0. Then whether I needed sending PTS to select protocol T=1 after receiving ATR ? If needed, how to send it ? Because ISO7816 3.4 Protocol type selection (PTS) said If only one protocol type and FI=D=1 (default value of TA1) and N smaller than 255 is indicated in the answer to reset. The transmission protocol associated to the protocol type may be started immediately after the transmission of answer to reset. So, I can't send PTS because Fi=9 and Di=5, and N=0xff. If not, the following operations such as SELECT FILE use which F and D(Fi, Di or Fd, Dd) ? I did'not found clear answers in ISO7916-3 about these things. May be I shoule read it once more. Oh, if you want *my* advice - I would get into pig farming rather than smartcard programming, it's a lot more rewarding and you can bring home the bacon at the end of the day ;-) A ha, You have a good sense of humor. But sometimes it's no choice. It's so long, thank you for your time. --- Best Regards, Bob ??5000 http://allyes.nie.163.com/main/adfclick?db=afaniebid=1698,833,77cid=148,4,1sid=1804show=ignoreurl=http://xyw.163.com/2009/yasui/ ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Compiling and linking a C++ program with a winscard.h library reference on Windows Vista.
Andrea Angella wrote: My name is Andrea and I'm doing a degree thesis about smart cards on Linux and Windows Vista platforms. I use Microsoft Visual Studio 2008 as a C++ development environment on Windows and I have a lot of difficults about compiling and linking a simple program with a winscard.h library reference. I know that I need to build a .lib file from winscard.dll that I can find in c:\windows\system32. I know that is possible to build this file using DUMPBIN and LIB utility as explained in this page: http://support.microsoft.com/kb/131313/en-us/. I tried but I don't know how to format a DEF file !!! Otherwise it's possible to find directly the generated .lib file from winscard.dll ? You need the Microsoft Platform SDK. See: http://en.wikipedia.org/wiki/Microsoft_Windows_SDK Someone could help me please ? ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] new CCID driver available: version 1.3.1
Ludovic Rousseau wrote: 2007/11/16, Douglas E. Engert [EMAIL PROTECTED]: The file: https://alioth.debian.org/frs/download.php/2193/ccid-1.3.1.tar.gz Appears to be identical to the ccid-1.3.0.tar.gz... What I had done was to change a wget script I had. I changed the 1.3.0 to 1.3.1 but did not change the 1970 to 2193. https://alioth.debian.org/frs/download.php/1970/ccid-1.3.1.tar.gz This file has the name 1.3.1 but has 1.3.0 files! I don't follow you. The file you mention above contains a README file with version 1.3.1. It also contains configure.in with version 1.3.1 What do you mean by Appears to be identical? They are or they are not? % wget https://alioth.debian.org/frs/download.php/1970/ccid-1 .3.1.tar.gz --15:42:28-- https://alioth.debian.org/frs/download.php/1970/ccid-1.3.1.tar.gz = `ccid-1.3.1.tar.gz' Resolving alioth.debian.org... 217.196.43.134 Connecting to alioth.debian.org[217.196.43.134]:443... connected. HTTP request sent, awaiting response... 200 OK Length: 566,794 [application/binary] 100%[] 566,794 197.96K/s 15:42:35 (197.66 KB/s) - `ccid-1.3.1.tar.gz' saved [566794/566794] atalanta.it.anl.gov% ls -l ccid* -rw--- 1 b17783 c250 566794 Nov 19 15:42 ccid-1.3.1.tar.gz atalanta.it.anl.gov% zcat ccid-1.3.1.tar.gz | tar tfv - | head -10 drwxrwxrwx 1000/1000 0 May 10 08:06 2007 ccid-1.3.0/ -rw-r--r-- 1000/1000 7746 May 10 04:16 2007 ccid-1.3.0/configure.in -rw-r--r-- 1000/100044 Feb 10 13:41 2007 ccid-1.3.0/AUTHORS -rw-r--r-- 1000/1000 763 Feb 24 11:41 2007 ccid-1.3.0/Makefile.am drwxrwxrwx 1000/1000 0 May 10 08:06 2007 ccid-1.3.0/build/ -rwxr-xr-x 1000/1000 32665 Apr 19 21:09 2007 ccid-1.3.0/build/config.sub -rwxr-xr-x 1000/1000 15936 May 10 03:53 2007 ccid-1.3.0/build/depcomp -rw-r--r-- 1000/1000267821 May 10 03:53 2007 ccid-1.3.0/build/aclocal.m4 -rw-r--r-- 1000/1000196719 Mar 11 12:49 2006 ccid-1.3.0/build/ltmain.sh -rwxr-xr-x 1000/1000 44573 Apr 19 21:09 2007 ccid-1.3.0/build/config.guess Bye, -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] new CCID driver available: version 1.3.1
Sorry about this, downloaded https://alioth.debian.org/frs/download.php/1970/ccid-1.3.1.tar.gz which did appear to be identical. The file: https://alioth.debian.org/frs/download.php/2193/ccid-1.3.1.tar.gz Appears to be identical to the ccid-1.3.0.tar.gz... Ludovic Rousseau wrote: Hello, I just released the version 1.3.1 of my CCID driver. This release mainly includes support for some more readers (11 new readers) and some minor bug corrections. You can download it from [1]. Bye, Changelog: 1.3.1 - 16 November 2007, Ludovic Rousseau - add support for Philips Semiconductors JCOP41V221 ICCD card, O2Micro oz776 (ProductID 0x7772), CardMan5321, Giesecke Devrient StarSign Card Token 350 and 550, SafeNet IKey4000, Eutron CryptoIdentity, Eutron Smart Pocket, Eutron Digipass 860, Lenovo Integrated Smart Card Reader, Kobil EMV CAP - SecOVID Reader III, Charismathics token, Reiner-SCT cyberJack pinpad(a) - improve support of Mac OS X and *BSD - some minor bugs removed [1] https://alioth.debian.org/frs/?group_id=30105 -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] new CCID driver available: version 1.3.1
The file: https://alioth.debian.org/frs/download.php/2193/ccid-1.3.1.tar.gz Appears to be identical to the ccid-1.3.0.tar.gz... Ludovic Rousseau wrote: Hello, I just released the version 1.3.1 of my CCID driver. This release mainly includes support for some more readers (11 new readers) and some minor bug corrections. You can download it from [1]. Bye, Changelog: 1.3.1 - 16 November 2007, Ludovic Rousseau - add support for Philips Semiconductors JCOP41V221 ICCD card, O2Micro oz776 (ProductID 0x7772), CardMan5321, Giesecke Devrient StarSign Card Token 350 and 550, SafeNet IKey4000, Eutron CryptoIdentity, Eutron Smart Pocket, Eutron Digipass 860, Lenovo Integrated Smart Card Reader, Kobil EMV CAP - SecOVID Reader III, Charismathics token, Reiner-SCT cyberJack pinpad(a) - improve support of Mac OS X and *BSD - some minor bugs removed [1] https://alioth.debian.org/frs/?group_id=30105 -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Remote connections to pcsc
Shawn Willden wrote: Hi everyone, I have a situation where it would be convenient to have a card reader connected to one machine, and the application using it running on another machine. It occurred to me that if libpcsclite were to use a TCP socket rather than a UNIX socket to connect to pcscd, this would be easy to accomplish. What are the security implications to doing this? How would the stream be protected? ssh? Windows Remote Desktop can forward the smart card under the Local Resources,Local devices and resources-more. I don't know if this is part of the protocol. There is an Open source version of RDC, rdesktop, but I don't know if it does smart cards. Has anyone tried this? Is the over-the-socket protocol platform-dependent? Would there be any issues with using a different platform on each end (OS/CPU)? I'm going to give it a try in the morning, but I thought it might be worth seeing if anyone in the community has any thoughts/warnings. Thanks, Shawn. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Remote connections to pcsc
Shawn Willden wrote: On Friday 21 September 2007 09:11:14 am Douglas E. Engert wrote: What are the security implications to doing this? In this particular case, I don't care. Both machines are to be deployed in a secure environment. In general, though, I think it also doesn't matter that much. Any reasonable secure smart card API (I'm talking about the APDU-level API) must assume that an attacker can get between the card and the reader, or the reader and the application. Not the ones I have seen. The assumption is the user of the card has physical control over the reader, and is using the machine in front of him. Having a remote reader offers another avenue of attack, but it's not like there aren't plenty to begin with. Yes there are, but not protecting the stream over the network just introduces another. The case where it might matter is when the card is used for user authentication, but a remote reader wouldn't make any sense for that application anyway. Yes it would, That is exactly what the Microsoft RDC can do, let you login to a remote computer using your smart card. How would the stream be protected? ssh? I don't see any value in layering encryption on the stream. If the data being transmitted is sensitive, it should be encrypted and/or MACed between application and card anyway. Or are you suggesting that ssh authentication be used to prevent rogue connections to the card? Both. That might be useful in the general case. In my case it doesn't matter -- and I'm looking to hack pcsclite to make it suit my needs, not necessarily to add a feature to the official pcsclite. Good luck. There is an Open source version of RDC, rdesktop, but I don't know if it does smart cards. There has been some work done on smart card support in rdesktop, but I'm not sure where it is. Even if it's functional, it doesn't address my situation. Thanks, Shawn. -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Reflex USB v3 reader on Solaris 9
Wei Hu wrote: Hi, Does anyone on this list have experience of making Reflex USB v3 reader working on Sun Sparc Solaris 9? I have installed SUNWlibusb package and CCID driver. Also I have build pcsclite 1.4.7 on this platform. But the reader still doesn't get recognized. Any experiences on this are greatly appreciated. Solaris 10 has libusb in /usr/sfw/lib. pcslite-1.4.2 and cc-d-1.3.0 and GemPC Twin works with something like: LIBUSB_CFLAGS=-I/usr/sfw/include LIBUSB_LDFLAGS=-L/usr/sfw/lib -lusb.so export LIBUSB_CFLAGS LIBUSB_LDFLAGS LDFLAGS=$LDFLAGS -Xl,-R,/opt/smartcard/lib,/usr/sfw/lib -L$MYLIBTOOL/lib I never had an luck with Solaris 9. Time to upgrade? Wei ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] OpenSC versus Musclecard
Ismael Valladolid Torres wrote: We're trying to add cryptographic support to GSM cards. What we're thinking is hacking some cryptographic application so it reads wirelessly its support files from a card inserted in a mobile phone and registered into the network. At first what we need is to make clear the scope where OpenSC is to be used and the scope where Musclecard is to be used. OpenSC reports that it's to be used with traditional smartcards with a file system, and suggests to avoid Java enabled cards, as they don't have a filesystem. But OpenSC also provides a way to write your own emulation driver that will emulate the file system or selected files on a card. The files do not have to exist on the card and you emulator gets to intercept all requests. The NIST 800-73-1 PIV card that I am working on is an example. Most PIV card vendors are using Java cards with the PIV applet preloaded. 800-73 defines the AID and the commands the applet must respond to which are object based, not file based. The card-piv.c and pkcs15-piv.c emulate a pkcs15 type file system with a fixed set of emulated files for the certs, pubkeys, prvkeys and data objects on the card. Pubkeys do not exist on the card, the pubkey is obtained from the cert and emulated to look like there is a pubkey file. But indeed GSM cards operators here are using are Java cards and do have a filesystem. Only from Java Card 2.2.2 on a filesystem is excluded (this means AFAIK that the package javacard.frameworkx is no longer available, am I right?) You may not need to deal with Java. It depends in the applet on the card. So OpenSC *could* be used with current GSM cards. Moreover Musclecard reports being available to Java cards, which include current GSM cards. Does this mean Musclecard don't make use of the filesystem in any way? Also, Musclecard implements PKCS #11 where OpenSC implements PKCS #15. What are the differences from a practical point of view between #11 and #15? But OpenSC implements a PKCS#11 on top of the PKCS#15. The opensc-pkcs11.so can be used by Mozilla for example. Also, is a cryptoprocessor in the smartcard needed for using also Musclecard and OpenSC? Yes and no. If private keys are stored on the smartcard such that they can not be read off the card, then to use them you must use the cryptoprocessor on the card. (That is the point of using a smartcard vs a memory card. You can't read the key, and thus have to use the card to respond to some authentication challenge in real time, thus proving you are in possession of the card.) Summarizing: Given that we need cryptographic support into a current GSM Java card, should we go for OpenSC or for Musclecard? Any ideas, comments or suggestions are welcome. Cordially, Ismael ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] RSA
David Corcoran wrote: Hi, We are at RSA this week in the MultOS booth in the Smart Card Pavilion. Would love to meet with any of you if you are here ... Wish I was there too, its below zero, snowing, and the Bears lost ... Thanks, Dave -- Identity Alliance TrustBearer Labs 3201 Stellhorn Road260-399-1648 Fort Wayne, IN 46815 http://www.trustbearer.com Visit us at the Innovation Center -- ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] No padding with CCID pinpad readers?
Peter Williams wrote: not responding to the query, but speaking of CCID given the vista release... anyone know if the CCID reader attached to the host machine of the _client's_ remote desktop session (the RDP5 protocol) can now be attached to the remote process? This scenario was possible for XP, when the reader was serial but not CCID/USB. Maybe I did not understand your configuration, but I have used as CCID/USB reader at home to login to a computer at work and have used a PCMCIA reader in a laptop to login to a computer at work. All XP pro. The fun part of this, for PCSC dev., is that one has to decide how the two host controller state machines collaborate, given either could demand exclusive control on behalf of its particular API consumer. From: [EMAIL PROTECTED] To: muscle@lists.musclecard.com Date: Mon, 4 Dec 2006 17:23:14 +0100 Subject: [Muscle] No padding with CCID pinpad readers? Hi, we have a card that uses unpadded pin buffers (e.g. 00 22 00 02 04 31 32 33 34 for a verify PIN) Looking at the CCID specs, could it be true that there's no support for this? (Sorry if asked before...) Thanks, Stef ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle _ All-in-one security and maintenance for your PC. Get a free 90-day trial! http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=wl_wlmail ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Driver for remote card reader (with proper linebreaks)
PCSC, (but I don't think it is in PCSC-lite), has the capability to make connections over the network. The Microsoft Remote Desktop Connection knows how share smart card readers along with disks, printers and serial ports I think hte RDC is using PCSC. Useful for smart card login. So rather then writing it from scratch, the question could be what would it take to get PCSC-lite to support network connections, and what would it take to get the Linux Terminal Server Client to use this. Thus there would be nothing to do in the Windows side as it already done. Peter Koch wrote: Dear MUSCLE mailing list: This is a windows related questing, so I should not ask it on the MUSCLE list. But maybe you can help or know a better place where to ask this. I would like to write a driver for a (virtual) card reader that will talk to a (real) card reader on a remote system. I'm trying to do this OS-independent. So it should be possible to connect to a card reader on a Windows-system from a unix system and vice-versa. So far I'm almost finished with an ifd_handler for pcsclite and a server-programm that has to run on the machine where the real card reader is located. I do know (at least in theory) how to write the server-programm such that it can be compiled under both unix and windows. But how do I write an ifd_handler under windows? I just got the Microsoft DDK from a friend. Do I have to write a WDM-driver (which would be a real pain for a unix-focussed person like me)? Or do I mistake writing a Windows-Driver with writing an IFD-Handler? I was hoping that writing an IFD_handler would be comparable to writing a GINA-dll or a PKCS#11-dll (which I have done in the past - without the need to use the DDK). But I cannot find any documentation about the Windows Smart Card Reader IFD-Handler API. Where can I find some sample source? What do you think about all this? All hints or comments are greatly appreciated. Peter Koch __ XXL-Speicher, PC-Virenschutz, Spartarife mehr: Nur im WEB.DE Club! Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Driver for remote card reader (with proper linebreaks)
Ludovic Rousseau wrote: On 25/10/06, Douglas E. Engert [EMAIL PROTECTED] wrote: PCSC, (but I don't think it is in PCSC-lite), has the capability to make connections over the network. The Microsoft Remote Desktop Connection knows how share smart card readers along with disks, printers and serial ports I think hte RDC is using PCSC. Useful for smart card login. So rather then writing it from scratch, the question could be what would it take to get PCSC-lite to support network connections, and what would it take to get the Linux Terminal Server Client to use this. Thus there would be nothing to do in the Windows side as it already done. I like this idea. Do you know if the protocol is publicly documented? Would it be possible to just use the smart card redirection? Don't know. I thought PCSC had some networking capabilities, and that was what Microsoft was using with the RDC. And I thought that you did not add the networking code to PCSC-lite. The Terminal Server Client-0.148 that is on Ubuntu Edgy is from: http://www.gnomepro.com/tsclient/ and is a frontend for the rdesktop http://www.rdesktop.org/ The rdestop appears to support sharing the comport, disk, lptport and sound. But I don't see anything about smartcard. I found a page on wikipedia [1] but they do not talk about smart cards. Bye, [1] http://en.wikipedia.org/wiki/Remote_Desktop_Protocol -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] Re: [opensc-devel] OpenCT and limiting us of the reader to the console user only
Andreas Jellinghaus wrote: Douglas E. Engert wrote: Is there any way to have OpenCT limit access to reader devices to the user logged in at the console? sure. chgrp scard /var/run/openct and configure some pam module for login only, so it adds the user to group scard. Ubuntu with openct 0.6.8.ubuntu1 does the chgrg scard /var/run/openct but does not appear to do anything with it. It also had groups like cdrom, floppy, audio, scanner., and added some users to these groups. that way only those who used login have group scard and can use openct, while those using ssh, kdm, whatever can not. That sounds like pam_console.so. But the best that I can tell, there is a security hole with this. UserA logs in at console, and get into group scard. UserA creates a program with setguid bit. They log off. Later userA logins via the network and are not part of group scard, then run the setgid program to look at card in reader from UserB. (Or something like that, dynamicly adding a user to a group for a session has problems.) This is a low risk problem, but it appears that that was one reason for HAL. I see the WIKI has some comments about using HAL, and the comment: Also so far noone told us why we should change a running system. Here is one reason: I would like avoid a user who has logged in over the network from accessing a card in a reader inserted by the local user. can be done without udev/hal changes, no issue here I think. I sent a similiar note to the muscle list asking about PCSC. sorry, I have little clue about pcsc. maybe ludovic knows? I guess you can set permissions on the pcsc sockets too. So has anyone looked at HAL closer for OpenCT? I see it has the udev files as a start. I think hal is nice if some application (e.g. your kde desktop icon manager) wants to get notification if e.g. a cdrom was inserted or a usb memory stick was plugged into the usb port. I fail to see how it helps openct at all. It looks like it more then the notification, its the ability for the deamon controlling the device to only allow the user at the console to access the device. The OpenCT ifdhandler would have to query hal somehow. But the hal documentation is hard to find. Maybe some future addition to OpenCT. Andreas -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] Re: [opensc-devel] OpenCT and limiting us of the reader to the console user only
Ludovic Rousseau wrote: On 19/10/06, Andreas Jellinghaus [EMAIL PROTECTED] wrote: Douglas E. Engert wrote: Is there any way to have OpenCT limit access to reader devices to the user logged in at the console? sure. chgrp scard /var/run/openct and configure some pam module for login only, so it adds the user to group scard. that way only those who used login have group scard and can use openct, while those using ssh, kdm, whatever can not. I sent a similiar note to the muscle list asking about PCSC. sorry, I have little clue about pcsc. maybe ludovic knows? I guess you can set permissions on the pcsc sockets too. I also proposed to change the permissions on the /var/run/pcscd.* files. Your idea of dynamically add a user in a particular group is very good. I think that this idea was droped in 2000 or so because of the ability of a user once in a group creating a program or script with the set group bit and then using this program at a later time to access the device when they should not. I believe hal was trying to address that problem. I would prefer smartcard as the group name to be more explicit. Ubuntu is using scard as a group with OpenCT. Do you know a PAM module that does that? pam_console was to change permisions on files, don't know of the one to add groups to a session. Bye, -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Limiting reader access to the console user only
Ludovic Rousseau wrote: On 17/10/06, Shawn Willden [EMAIL PROTECTED] wrote: On Tuesday 17 October 2006 01:13, Ludovic Rousseau wrote: How can you differentiate, at the system level, a local user from a remote user? I don't think you need to distinguish a user at the console from the same user account coming in over a remote connection. What Mr Engert wants to achieve is to ensure that when a user logs into the console, only that user account has access to the smart card. Since the display manager obviously knows who is logged in at the console, that should be achievable. Yes that would be acceptable. What you could do is add a PAM module that changes the permission of the /var/run/pcscd.* file. You should also manage the case when two users are logged using two local X servers or from two local virtual text consoles: only the first user (uid) will have access to the smart card. At the logout the same PAM module would change the permissions back to their original states. There are a lot of other devices which need to be usable only by the user at the console: speaker, microphone, thumb drive, scanner, camera as well as the keyboard, and mouse. There appears to be a number of approaches to handling this. Linux has udev and hal, that create devices and assign names and permissions to these dynamic devices. There is also pam_foreground and pam_console that try to identify the user that is at the console, and create a /var/run/console/ entry for the user. The pam_group can add groups to a session. (But there is a security problem with this if the user creates a setgid program while at the console, then misuses it at a later time.) On Ubuntu Edgy that I am working with since it has OpenSC-0.11.1 the /var/run/console appears to be created. But did not delete it when I logged off, and on with a different user. I am still looking to see how these are used. Such a solution would work even without modifying pcsc-lite. That would be nice. But keep in mind that you may have a hardware crypto device for the system and a smartcard reader for the user, both serviced by pcscd. In this case you may want to control access at the reader level rather then the pcscd socket level. Bye, -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] Limiting reader access to the console user only
Is there any way to have PCSC limit access to reader devices to the user logged in at the console? I would like avoid a user who has logged in over the network from accessing a card in a reader inserted by the local user. -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [opensc-user] Re: [Muscle] Muscle card support for OpenSC - solved this problem
Thanks for the list! While doing testing of NIST 800-73-1 PIV cards with OpenSC, some cards expect to transfer 256 bytes of data at a time, and thus need readers on the full lenght list. No wonder I was having troubles with an Active Card v2 reader, even after upgrading the firmware. Ludovic Rousseau wrote: On 14/09/06, Thomas Harning [EMAIL PROTECTED] wrote: On Wed, 13 Sep 2006 16:32:57 -0700 Iain MacDonnell [EMAIL PROTECTED] wrote: commands.c:1039:() Command too long (260 bytes) for max: 253 bytes ifdwrapper.c:735:() Card not transacted: 612 winscard.c:1481:() Card not transacted: 0x80100016 Looks to me like the reader is one of those that doesn't support full 260-byte commands. I'm putting together a build that is less hard-coded as to what the maximum data length is (it's going to be in a 'define'). I don't know how I would access the actual maximum APDU length allowed... I had a look on the CCID readers I have and they can be divided in mainly two parts. Those supporting a max of 253 bytes (max CCID frame of 263 bytes) and those supporting a max of 261 bytes (max CCID frame of 271 bytes). You can check for yourself by searching dwMaxCCIDMessageLength in the readers descriptions available at [1]. Here is the lists I have: 261 bytes (full length): ACR38U-CCID ActivkeySim ASEDrive_IIIe_KB ASE_IIIe AU9520 CardMan3021 CardMan3121 CardMan3621 CardMan3821 CardMan5125 CardMan6121 CherryST1044U CherryXX33 CherryXX44 CL1356T CryptoIdentity DellSCRK DellSK-3106 GemCoreSIMPro GemCoreSIMPro GemPC433_SL GemPC_Express GemPCKey GemPCPinpad GemPCTwin id3_CL1356D iDream KAAN_Advanced KAAN_Base KAAN_SIM_III LTC31 LTC31v2 mIDentity2 mIDentity MySmartPad Oz776S sid800 SIM_Pocket_Combo SIM_Pocket_Combo SK-3106 US777-3 US777-5 US777-7 Verisign_secure_storage_token Verisign_secure_token 253 bytes (somewhat limited): ActivCardV2 ActivCardV3 AxaltoV3 CherrySmartTerminalST2XXX HPUSBSmartCardKeyboard SCR3310 SCR3311 SCR331-DI-NTTCom SCR331-DI-NTTCom SCR331-DI SCR331 SCR3320 SCR333 SCR3340 SCR335 SCR355 SDI010 I also have 3 special cases: OCS-R03: 251 bytes SPR532: 260 bytes Winbond: 128 bytes So if you have to select a reader you may use this criteria. The SCM SCR 3310 you have Iain is not is the best list. Bye, [1] http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/readers/?rev=0sc=0 -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] RE: CAC and musclecardframework
Timothy J. Miller wrote: Todd Denniston wrote: You are probably a little better in the know than me, so please clarify. I thought that all the new 64K cards were coming with the PIV applet, is that incorrect? I just double-checked: Based on testimony, there is no 32k stock in the issuance pipeline any more; it's all 64k now. No cards will be issued with the PIV applet until October of this year. Note that this is about production cards. You can certainly get test cards with the PIV applet. In fact, the guy two desks over has one. What we don't have is middleware (yet). OpenSC-0.11.0 has PIV support via PKCS#11. The intent was to provide the client side routines. But for testing the piv-tool can initialize some test cards if you know the keys and particulars of the card you are using. I have been testing this with a number of beta PIV cards, including the Oberther card which matches NIST 800-73-1. By using the piv-tool I can have the card generate a key pair, use this to generate a certificate request, get the requests signed by a Microsoft CA, then use the piv-tool to load the certificate to the card. I can then use this with Windows login, using the Identity Alliance CSP, or with IE via the CSP or Mozilla via PKCS#11. On LINUX I can use to with Mozilla, and can even use it with Heimdal Kerberos with PKINIT via PAM to login to LINUX using the Windows AD as the KDC. In this testing mode, the certificate is a Windows compliant certificate and not fully PIV compliant certificate. If the guy two desks over from you wants to try this, have him drop me a note. Are you Indicating that after October, we will start having yet another applet to build support for, i.e., the CAC bundle we are grabbing from Apple will not work with the PIV? Starting in October, DoD starts issuing cards with both the CAC v2 and PIV applets from the first upgraded DEERS/RAPIDS workstation. Transition to PIV-only cards (i.e., no CAC applets) should start three years after the last DEERS/RAPIDS workstation is upgraded to issue the PIV cards. We're expecting that the total time from the October start to issuing PIV-only cards will be ~4 years. The current CAC bundle should work so long as there are CAC applets on board, and that will be true for a while. Personally, I'd think it would be easier to build a brand-new PIV plugin than to evolve the CAC plugin, especially since PIV-transition is *only* for DoD. OGA's that currently have no smartcard tokens start out with PIV from day one. Oh, and the NSA can throw a wrench into this schedule at any time, just to keep things interesting. -- Tim ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] PKC#$15, GCs, PIV, musclecard architecture of VMs/FS
Peter Williams wrote: Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 Douglas, Perhaps could you explain where I may be mis-understanding recent issues, on the PIV/PKCS#15 topic, on the list? The misunderstanding comes in respect ot PKCS$15 - which is a cross between a stream, and a file _system_ defined over 7816-4 files (and their acls). PKCS#15 is esseentialy a file system defined over the ISO 7816-4 files - MF/DF/EFs,m etc. V1.1 is obtained from ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs15v1.doc. The cited URL links to the document that was - apparently - the progenitor for ISO 7816-15 (drafts). But, what is the relationship formally of PKCS#15/7816-15 to PIV, and where can that info be seen in USG-issued _public_ documents? NIST 80-73 Table 1 and Appendix A lists the objects on the card, and also lists what they call a Container ID. These could be looked at as the EF in the current directory. (They maybe holdovers from some previous documents.) Also note that the PIV SELECT command is a 7816-4 select DF. But the PIV application is not required to respond to read/write binary, or any other select command, only to the GET/PUT DATA commands, that don't use these Container IDs, but rather use the BER-TLV Tags from Table 6. What I was saying was that in the OpenSC there is the concept of emulation of a PKCS#15 file system on cards that are not PKCS#15. This is the approach I took, so the OpenSC PKCS#11 implementation could be used against the PIV card. The OpenSC pkcs15-tool and pkcs11-tool and libp11 can then access the objects on the card. So the usable API is PKCS#11 not PKCS#15. If we reference muscle, we also know that musclecards come in a variety of card-types, for a common card-edge: the javacard (VM?) form of the muscle applet that Karsten has recently amended, and the ISO FS form sold by some vendors (apparently). The muscle download area has C-coded plugins for the two sets of wire format PDU encoders, bendath a common musclecard API - for the VM [aka javacard] applet, and the FS card. But the FS card does not export a PKCS#15 file system - it simply provides the muscle card-edge! Is the PIV concept of a FS card type an extension of the muscle FS card concept? ... in which the card edge can not only be implemented in terms of classical 7816-4 file access/management instructions (READ/WRTIE BUFFER etc) but the collection of files MUST also conform to PKCS#15 (or 7816-15) - creating a PKCS#15 filesystem? I don't think it is that formal. The PIV does not support READ/WRITE only GET/PUT. As I stated above the ContainerID looks a lot like a EF, but the ContainerID are not used on the card, the BER-TLV Tags for the objects in Table 6 are used with the Get/PUT DATA. Now, finally, when discussing OpenSC, and its PIV driver mode: can I assume that this host-side driver is willing to emulate the existance of a PKCS$15 complygin file system on a PIV card - even when the card only implements a VM type card edge? Yes, but its a fixed files system with 4 certificates, 4 public keys, 4 private keys, 2 pins, and 6 or 7 objects. (NIST 800-73-1 has only one fingerprint object now.) The public key objects don't really exist at all but the public key can by derived from the certificate. You can not added additional objects of your own. How far could such an emulation go? for example, if one wanted to clone a card and thus get the source card to export the entire PKCS#15 ASN.1-defined BER stream, could the SC driver perform that sttream level of emulation, and then the reverse process...write a stream back to a set of GC instance(s) and their PIV-data containers - on a VM-style PIV card? Some of this. But you can't read the private keys from the card. The PIV is designed to be issued by some agency, using the tools of the card vendor to initialize the card when all the objects are written to the card. NIST 800-73 does not standardized the personalization processes. It really only standardizes the use of the card in the field which is read objects and certificates and use the private key for crypto operations. But there is enough code in the OpenSC piv-tool to let you do most of the administration if you know some specifics about the vendor's card. The piv-tool can change the pins, generate keypairs, and write certificates and other objects to the card. I made no attempt to try and format the CCC, CHUID, Fingerprint buffer or security object buffer. The piv-tool could write them to a card given a file with the object. The PKCS#11 could read them if they are on the card. One of the problems is getting cards from the vendors, as they are still under development and each has its own set of bugs. The chaining of the GET/PUT DATA is also new, and some early cards did not handle this well. Since thse are test card, I have not atempted to finailize the cards in any
Re: [Muscle] Restricting reader/card access by user account
Shawn Willden wrote: That leads to either requiring the user to enter their PIN many, many times, or to implementing some mechanism to cache the PIN Not if the reader has a number pad to enter the PIN, which is were I think most security people would like to get to, so that they and the user knows the PIN has not been stolen. Shawn ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
Scott Guthery wrote: Just as a note in passing, the ISO/IEC 7816-4 GET DATA and PUT DATA commands for reading and writing TLV data objects do NOT require a file system. The PIV card application is an example of this approach. And the PIV responds to a select of A0 00 00 xx xx 00 00 10 00 where NIST published on 10/6/2005 that xx xx is 03 08 See NIST 800-73-1 OpenSC has some code to use the PIV cards, usable with PKCS#11 applications. Cheers, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shawn Willden Sent: Tuesday, March 21, 2006 5:16 PM To: muscle@lists.musclecard.com Cc: Peter Tomlinson Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21 On Tuesday 21 March 2006 14:38, Peter Tomlinson wrote: There is provision in ISO/IEC 7816 for a card to identify itself in several ways, but the majority of card suppliers either do not encode the necessary information or encode it inadequately - or it gets changed to something else during personalisation. Typically the ATR may be the starting point, or there may be extended information in an ATR File - and there may also be a DIR file giving a directory of card applications. (EMV of course has its own method of application selection.) GlobalPlatform also has provision for ID information, using data objects stored at the MF level. Both of which require a 7816 file system (or enough of one, anyway). As more and more Javacards are deployed, fewer cards have a file system :-/ We are still in the mindset that thinks bytes are extremely expensive, and we need to get out of that and do the job properly. What's funny about that is I've seen one system that fires literally dozens of APDUs at a card in an attempt to determine what is on it... it would take far fewer bytes to query a file structure. Shawn. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
Peter Williams wrote: Ah, So we select a discovery application, once we recognise a std ATR, rather than a MF/EF/DF ISO file system. Yes, thats what it looks like NIST has defined for the PIV. So multiple vendors can can provide cards with their version of the PIV applet. Then we GET/PUT the object-file-store hosting application data, and object data - rather than READ/WRITE records in ISO files. ok Correct. We for PIV, we do a funky GET/PUT for TLV objects, renamed by ISO 8824 tagging, that sort of map onto interface discovery ids, and a PKCS#15 stream (which has only context tagging), but which all uses ISO file system acls, acl management, and logical channels to control host-applet security. Yes, but the NIST PIV is very specific about what objects there are on the card, and what the ACLs are for the objects. The NIST 800-73 is desigend to provide interoperability for the use of the card, but not nessesarily on the administraiton of the card, leaving up to the vendors to provide the initialization/personalizsation with their card administration packages. This contrasts with simply reading a PKCS#15 stream from an ISO file system over SCP02015 (remember the ISO files were admittedly not designed for streams), or interact with an applet supporting PKCS#15 stream navigation. What the OpenSC code does is to in effect to make cards look like it has a fixed pkcs#15 file system, which allows the use of PKCS#11 on top of this to use the X.509 Certificate for PIV Authentication and its private key from PKCS#11 applications, like browsers or Kerberos PKINIT. So, assuming that the PIV design concept is to put the semantics of PUT/GET now into the host/TPM driver, rather than in an ICC-side applet for navigating the PKCS#15 stream, we make a giant step backwards I agree, its looks like a step backwards. For example if an object was never added to the card, it is not obvious what the get data should return. But the PIV is a specific applet with specific objects it is designed to support. You don't get to add your own objects, at least not into the PIV applet. You could have other applets on the card with other data, as well as a PKCS#15 file structure. in favor of yet more driver hacks, per card (discovery applet). Control over end-end process interaction does however pass to the TPM however... which is probably the (unstated) point of USG's design concept - to ensure the national id card works with the TPM-based secure storage control, to control a core's functional set arming, motherboard bus enumeration discovery beneath the Intel ACPI, etc And who was it who said that the European design concepts were complicated, and unweildy? having said all that, been looking at some PIV hardware prototypes. 25mAh rechareable battery-backed always on card via USB-enabled 7816-1 module, with chip on flex micro manufacturing, with buttons, flexi-display for OTP, emulated swipe strip, and Mifare contactless capaility via internal antenna conenctivity into the back of the die. Nice USB-SIE enabled AVR-based 144k ROm, 144k eeprom for NSA's javacard silos, with 6k RAM. Default Applets should come with RSA's KIP, for configuring the OTP device over the wire ,for different C/R schemes, and to resync the temp-sensitive clock. All in all, software + hardware, its all very complicated... leading edge... and at risk, becuase of those facts alone. From: Douglas E. Engert [EMAIL PROTECTED] Reply-To: MUSCLE muscle@lists.musclecard.com To: MUSCLE muscle@lists.musclecard.com CC: Peter Tomlinson [EMAIL PROTECTED] Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21 Date: Wed, 22 Mar 2006 15:51:14 -0600 Scott Guthery wrote: Just as a note in passing, the ISO/IEC 7816-4 GET DATA and PUT DATA commands for reading and writing TLV data objects do NOT require a file system. The PIV card application is an example of this approach. And the PIV responds to a select of A0 00 00 xx xx 00 00 10 00 where NIST published on 10/6/2005 that xx xx is 03 08 See NIST 800-73-1 OpenSC has some code to use the PIV cards, usable with PKCS#11 applications. Cheers, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shawn Willden Sent: Tuesday, March 21, 2006 5:16 PM To: muscle@lists.musclecard.com Cc: Peter Tomlinson Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21 On Tuesday 21 March 2006 14:38, Peter Tomlinson wrote: There is provision in ISO/IEC 7816 for a card to identify itself in several ways, but the majority of card suppliers either do not encode the necessary information or encode it inadequately - or it gets changed to something else during personalisation. Typically the ATR may be the starting point, or there may be extended information in an ATR File - and there may also be a DIR file giving a directory of card applications. (EMV of course has its own method of application selection
Re: [Muscle] Is it SunOS or is it Solaris?
Ludovic Rousseau wrote: On 04/03/06, Iain MacDonnell [EMAIL PROTECTED] wrote: libmusclecard uses `uname` (SunOS) for MSC_ARCH. muscleframework/MCardPlugin uses Solaris (in installBundle). CCID uses Linux (and breaks - patch for that coming, but I need to know...) Is it SunOS or is it Solaris? Who owns this decision? Personally, I don't really care ... so long as we're consistent... I looks like SUN is using Solaris (at least on their main web page). So I vote for Solaris. uname on a Solaris 10 use SunOS: SunOS .xx.anl.gov 5.10 Generic_118822-25 sun4u sparc SUNW,Sun-Fire-V240 I would go with whatever uname returns. Patches are welcome. Bye, -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] New pcsc-lite 1.2.9-beta9 available
Two problems:
(1) minor problem that may have been around before:
The libpcsclite.pc created with pcslite-1.2.9-beta9 has:
includedir=${prefix}/include/PCSC
When pkgconfig is used with ccid-0.9.4 the code tries to
include PCSC/pcsclite.h and PCSC/ifdhandler.h
which are not found as directory levels don't match.
One or the other should be changed.
(2) In previous versions of ccid I set CPPFLAGS=-I/$prefix/include
to get around (1) before running configure. In ccid-0.9.4, the CPPFLAGS
appears to be ignored. It looks like configure.in line 135 is in error:
--- ,configure.in Fri Nov 25 08:32:38 2005
+++ configure.inMon Nov 28 11:36:54 2005
@@ -132,7 +132,7 @@
AC_CHECK_LIB(usb, usb_get_string_simple, [LIBUSB=$LIBUSB -lusb],
[ AC_MSG_ERROR([your libusb is too old. install version 0.1.7
or above]) ])
- CPPFLAGS=$saved_LIBS
+ CPPFLAGS=$saved_CPPFLAGS
LIBS=$saved_LIBS
fi
AC_SUBST(LIBUSB_CFLAGS)
Ludovic Rousseau wrote:
Hello,
I just released a new version of pcsc-lite. It is version 1.2.9-beta9
and is available at [1].
Changelog:
pcsc-lite-1.2.9-beta9: Ludovic Rousseau
27 November 2005
- add/improve support of PIN pad readers
. define HOST_TO_CCID_16() and HOST_TO_CCID_32() macro to convert 16 and
32-bits data to the CCID format (replace HOST_TO_CCID)
- add support of SUN C compiler and try to avoid GCC specific features
(Heiko Nardmann)
- SCardGetStatusChange():
. exists if the list of readers changed (one reader added) so that the
application can update its list of readers (Najam Siddiqui)
. correct a bug when two contexts where used (Najam Siddiqui)
- add support of Solaris 10 IFDhandler (Douglas E. Engert)
- allow pcsc-lite to be compiled without (f)lex installed
- add a TODO file. Help/money needed here.
- improve Doxygen documentation
- some other minor improvements and bug corrections
I hope it will be the last beta version before the awaited stable
version 1.3.0. So please test it and report any bugs.
Thanks,
[1] https://alioth.debian.org/project/showfiles.php?group_id=30105
--
Dr. Ludovic Rousseau
For private mail use [EMAIL PROTECTED] and not big brother Google
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
--
Douglas E. Engert [EMAIL PROTECTED]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] SCLOGON 0.1 Smart Card event daemon for GNU/Linux
Karsten Ohme wrote: Ludovic Rousseau wrote: On 07/11/05, Martin Paljak [EMAIL PROTECTED] wrote: From the GDM list i heard that PAM should be capable for doing such operations like reacting on card insertion and reagin the username itself, but that's something that shoudl be possible by design but none of the examples i worked with provided such examples. AFAIK gdm calls PAM only _after_ login is filled. I may be wrong and that would be a good news. E.g. if MusclePAM is installed, PAM is called and if a smart card is inserted, gdm requests to enter the PIN. So gdm seems to have knowledge when a smart card is present. (Maybe this is because of my modified version of MusclePAM.) But gdm has the bug, that the dialog, e.g. Please enter PIN is duplicated after the selected window manager starts. Is that a bug, or that gdm is run as root, and remains running in the background waiting for the user to logoff. While the window manager would be running as the user. The session to the card most likly has been reset. Is there a way to pass it on to the window manager? Should there be? (I don't like pin caching and if the reader has a pin pad there is no pin to cache.) Karsten Bye, -- Dr. Ludovic Rousseau For private mail use [EMAIL PROTECTED] and not big brother Google ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pkcslite and libmusclecard on solaris box
Wei Hu wrote: Hi Doug, I am still getting the no readers found error from opensc-tool after compiled pcsclite with --enable-scf and opensc with --with-pcsclite. Is there a conf file for solaris? Testpscs from pcsclite does show the reader information, but opensc-tool dosen't. This time ocfserv -D did produce some output when I started opensc-tool -l. I've attached the output in the email. Would you also send me the ocfserv -D output when you are doing 'opensc-tool -l' on your system so I can compare the results? Looks like the problem is the Solaris smartcard reader is not setup: Authenticated uid: 0 http_req return: htmltitleSolaris Smart Card Project/title head/OCF/OCFService/listReadersConfigured/head bodyOCFstatus=OCF_Success list= /body The list= should have some 20 charater base64 hash(?) or index. Did you run this command: smartcard -c admin -t terminal \ -j com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory \ -x add -d /dev/scmi2c0 -r InternalReader -n SunISCRI Do you have a /dev/scmi2c0 What does the smartcard -c admin show? It should have a line with OpenCard.terminals = com.sun.opencard.terminal.scm.SCM2c.SCMI2cCardTerminalFactory|InternalReader|SunSCRI|/dev/scmi2c0 Many thanks, Wei I am trying to make it work on my solaris 9 box too. So far I've added the reader and I want to know how you use opensc-tool to see a card. I am pretty new to this area so some details are appreciated. You had to build the pcsclite with --enable-scf Then build the opensc with the --with-pcsclite Then with the Solaris /usr/sbin/ocfserv -D running try: opensc-tool -l Readers known about: Nr. Driver Name 0 pcsc InternalReader opensc-tool -a should then show the ATR ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pkcslite and libmusclecard on solaris box
Wei Hu wrote: Hi Doug, I am trying to make it work on my solaris 9 box too. So far I've added the reader and I want to know how you use opensc-tool to see a card. I am pretty new to this area so some details are appreciated. You had to build the pcsclite with --enable-scf Then build the opensc with the --with-pcsclite Then with the Solaris /usr/sbin/ocfserv -D running try: opensc-tool -l Readers known about: Nr. Driver Name 0 pcsc InternalReader opensc-tool -a should then show the ATR Many thanks, Wei From: [EMAIL PROTECTED] on behalf of Douglas E. Engert Sent: Mon 8/8/2005 7:59 AM To: MUSCLE Subject: Re: [Muscle] pkcslite and libmusclecard on solaris box Wei Hu wrote: Do you have two internal readers? Make sure you do have /dev/scmi2c1 on your system. No. But looking closer I did not use the correct device. The Sun Balde 1500 with Solaris 9 defines /dev/scmi2c0 This worked. Starting the ocf server with debug in one window as root: /usr/sbin/ocfserv -D Then in another window as root: smartcard -c admin -t terminal \ -j com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory \ -x add -d /dev/scmi2c0 -r InternalReader -n SunISCRI Stoping and restarting the ocfserv server. ^C /usr/sbin/ocfserv -D Then to see the parameters: smartcard -c admin -t terminal I am now able to use the opensc-tool to see a card which was the real goal. Thanks to Amit, Wei and Sim. Wei From: [EMAIL PROTECTED] on behalf of Douglas E. Engert Sent: Fri 8/5/2005 9:23 AM To: amit danayak; MUSCLE Subject: Re: [Muscle] pkcslite and libmusclecard on solaris box I too am looking at using the internal reader on a Sunblade 1500 with Solaris 9. I have the same set of libs as Wie Hu has, and have tried the GUI and now the command line wihc fails below. amit danayak wrote: Hi Wei, These are the Steps for Configure Internal Reader on Solaris 8/9 Make sure you have installed the following patches (check for the latest revision on sunsolve.sun.com) for smartcards, 110457, 109887 and 109695 Run the following command to activate the reader command to activate reader : smartcard -c admin -t terminal -j com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory -x add -d /dev/scmi2c1 -r MyInternalReader -n SunISCRI Well I tried it with /dev/scmi2c1: # smartcard -c admin -t terminal -j \ com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory -x add \ d /dev/scmi2c1 -r MyInternalReader -n SunISCRI Error: Classname, devicename, userfriendly readername, readername, IFD handler library or action argument is missing. where MyInternalReader: whatever you want to name the reader then Restart ocfserv and Add ATR for smartcard. If you have any probs let me know ... Smiles Amit On 8/2/05, Wei Hu [EMAIL PROTECTED] wrote: I have a sparc box with solaris 9 installed. It also comes with an internal reader. I compiled the pkcslite and libmusclecard on that system and now want to make it work on the internal reader. Dose anyone have successfully make it work on Sun's internal reader? What kind of driver should I specify in /etc/reader.conf? Thanks, Wei ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pkcslite and libmusclecard on solaris box
Wei Hu wrote: Do you have two internal readers? Make sure you do have /dev/scmi2c1 on your system. No. But looking closer I did not use the correct device. The Sun Balde 1500 with Solaris 9 defines /dev/scmi2c0 This worked. Starting the ocf server with debug in one window as root: /usr/sbin/ocfserv -D Then in another window as root: smartcard -c admin -t terminal \ -j com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory \ -x add -d /dev/scmi2c0 -r InternalReader -n SunISCRI Stoping and restarting the ocfserv server. ^C /usr/sbin/ocfserv -D Then to see the parameters: smartcard -c admin -t terminal I am now able to use the opensc-tool to see a card which was the real goal. Thanks to Amit, Wei and Sim. Wei From: [EMAIL PROTECTED] on behalf of Douglas E. Engert Sent: Fri 8/5/2005 9:23 AM To: amit danayak; MUSCLE Subject: Re: [Muscle] pkcslite and libmusclecard on solaris box I too am looking at using the internal reader on a Sunblade 1500 with Solaris 9. I have the same set of libs as Wie Hu has, and have tried the GUI and now the command line wihc fails below. amit danayak wrote: Hi Wei, These are the Steps for Configure Internal Reader on Solaris 8/9 Make sure you have installed the following patches (check for the latest revision on sunsolve.sun.com) for smartcards, 110457, 109887 and 109695 Run the following command to activate the reader command to activate reader : smartcard -c admin -t terminal -j com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory -x add -d /dev/scmi2c1 -r MyInternalReader -n SunISCRI Well I tried it with /dev/scmi2c1: # smartcard -c admin -t terminal -j \ com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory -x add \ d /dev/scmi2c1 -r MyInternalReader -n SunISCRI Error: Classname, devicename, userfriendly readername, readername, IFD handler library or action argument is missing. where MyInternalReader: whatever you want to name the reader then Restart ocfserv and Add ATR for smartcard. If you have any probs let me know ... Smiles Amit On 8/2/05, Wei Hu [EMAIL PROTECTED] wrote: I have a sparc box with solaris 9 installed. It also comes with an internal reader. I compiled the pkcslite and libmusclecard on that system and now want to make it work on the internal reader. Dose anyone have successfully make it work on Sun's internal reader? What kind of driver should I specify in /etc/reader.conf? Thanks, Wei ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pcsclite repository moved from CVS to SVN
Ludovic Rousseau wrote: Hello, I moved the source code repository from CVS to SVN (subversion). The CVS version is still online but will not change any more. I may remove the CVS repository it in the future to avoid problems. I was trying to get the last version of the CVS repository today using: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/pcsclite login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvsroot/pcsclite CVS password: cvs [login aborted]: unrecognized auth response from cvs.alioth.debian.org: cvs: WARNING: Read-only repository access mode selected via `cvs -R'. as stated stated on https://alioth.debian.org/scm/?group=30105 Did this last change cause this problem? You can access the subversion repository from (1] project pcsclite. I can also convert the muscleapps and muscleplugins repository if needed/requested. Bye, [1] http://svn.debian.org/ I don't have subversion yet, but if that is the solution, I will look at installing it. Thanks. -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] pkcslite and libmusclecard on solaris box
I too am looking at using the internal reader on a Sunblade 1500 with Solaris 9. I have the same set of libs as Wie Hu has, and have tried the GUI and now the command line wihc fails below. amit danayak wrote: Hi Wei, These are the Steps for Configure Internal Reader on Solaris 8/9 Make sure you have installed the following patches (check for the latest revision on sunsolve.sun.com) for smartcards, 110457, 109887 and 109695 Run the following command to activate the reader command to activate reader : smartcard -c admin -t terminal -j com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory -x add -d /dev/scmi2c1 -r MyInternalReader -n SunISCRI Well I tried it with /dev/scmi2c1: # smartcard -c admin -t terminal -j \ com.sun.opencard.terminal.scm.SCMI2c.SCMI2cCardTerminalFactory -x add \ d /dev/scmi2c1 -r MyInternalReader -n SunISCRI Error: Classname, devicename, userfriendly readername, readername, IFD handler library or action argument is missing. where MyInternalReader: whatever you want to name the reader then Restart ocfserv and Add ATR for smartcard. If you have any probs let me know ... Smiles Amit On 8/2/05, Wei Hu [EMAIL PROTECTED] wrote: I have a sparc box with solaris 9 installed. It also comes with an internal reader. I compiled the pkcslite and libmusclecard on that system and now want to make it work on the internal reader. Dose anyone have successfully make it work on Sun's internal reader? What kind of driver should I specify in /etc/reader.conf? Thanks, Wei ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] build problem on Solaris 9
gcc is trying to call the assembler as. It looks like the gcc is expecting it at /usr/ccs/bin/as This directory has the Solaris development tools do you have this package installed? Vincent Diluoffo wrote: I have downloaded both pcsc lite 1.2.9 rel 7 and pcsc lite 1.2 with the same error. I have Solaris 9 with gcc 3.4.2 installed. The following error is being seen: bash-3.00$ ./configure checking for a BSD-compatible install... /opt/sfw/bin/ginstall -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... gcc checking for C compiler default output... configure: error: C compiler cannot create executables See `config.log' for more details. bash-3.00$ listing from config.log: configure:2264: $? = 0 configure:2266: gcc -v /dev/null 5 Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.2 configure:2269: $? = 0 configure:2271: gcc -V /dev/null 5 gcc: `-V' option must have argument configure:2274: $? = 1 configure:2298: checking for C compiler default output configure:2301: gccconftest.c 5 gcc: installation problem, cannot exec `as': No such file or directory configure:2304: $? = 1 configure: failed program was: | #line 2277 configure | /* confdefs.h. */ Any idea? Thanks, Vince Smart Card Solutions Center of Competency 203 486 7623 (t/l 376) FAX: 203 486 5755 (t/l 376) e-mail: [EMAIL PROTECTED] ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] GEM SC + MUSCLE + PCSC usage..
Serdar KOYLU wrote: I have many SC Readers and samrtcards. But my primary focus is a GEM SC. Readers installed correctly: OMNIKEY, GEMTWIN, CASTLE EZUSB etc.., functionality can seem right. This cards ATR is: 3B 7D 94 00 00 80 31 80 65 B0 83 01 02 90 83 00 90 00 In contact area, GEMPLUS word readed easily. No more information :( Where these cards used with Windows? Look at the OpenSC development, as there is a gemsafe emulation mode that might work. I search web and reach many ATR lists. Don't find any match. But 3B 7D 94 00 00 80 31 80 65 B0 83 01 01 90 83 00 90 00 GemSafeXpresso 16k R3.2 This card ATR very similar and only 2 bit different.. I try opensc-explorer, gpg[sm] etc. But its can't help for me.. opensc-exp.. or others always broken with Wrong Length error. I made a simple hack to opensc-explorer and insert cards ATR to JCOP cards list. opensc-explorer runned, select DF = 3F00 and ls command show a file with Size = 128. This card already personelized. I want information from cards provider. He say Its application is PKCS#11.. Currently, our information only this. I try MUSCLE FRAMEWORK and other utils. Its refered a directory /usr/local/pcsc/services but no access request countered on sources or strace results to this directory. I'm completely refused. If you are provide usage of MUSCLE Framework etc. usage, I can provide more effort for MUSCLE. I don't find any document for usage of MUSCLE. Thanks.. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Example PIV applets
Dave, Are there any pkcs#11 or #15 libs from Muscle or OpenSC to use these applets? Are there any java test programs to run the applets and to simulate a card? Corcoran David wrote: Hi, I uploaded the Michigan State PIV II Java Card applets - I had missed transferring them when we switched servers. Here is the download URL to those that are interested: http://www.identityalliance.com/downloads/PIV-II-MSU.zip Thanks, Dave David Corcoran[EMAIL PROTECTED] Identity Alliancehttp://www.identityalliance.com phone: 260-488-3099 fax: 260-488-2455 Smart Cards, Biometrics, Training, Identity Management - ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] Alternatives to OpenSC?
Geoffrey Elgey wrote: G'day, Martin Paljak wrote: You can use whatever pkcs11 module with opensc pkcs11 openssl engine - for example muscle pkcs11. My understanding is the the OpenSSL PKCS#11 engine in OpenSC relies on a PKCS#11 implementation on the path. o If the card in the reader is a Cyberflex e-gate 32K card (a java card), then the PKCS#11 library provided by muscle is required (and the muscle applet must be loaded onto the card). o If the card in the reader is a Cryptoflex 32K card (a file-based card), then the PKCS#11 library provided by OpenSC is required (and the card must have a PKCS#15 file structure). Is that correct? Sort of. But the OpenSC code now has pkcs15-emulation routines, which emulate pkcs15 file operations on a non-pkcs15 card. So if one was written to work with the Muscle applet, you could use the OpenSC PKCS11 that calls the OpenSC PKCS15. The choice of the emulation can be controlled by the opensc.conf and based on the ATR. (I have been working on a GemSAFE emulator this month.) I'm wondering what happens if I use a Cyberflex card in the reader, then pull it out and use a Cryptoflex reader. It seems that the OpenSSL PKCS#11 engine must invoke a different PKCS#11 implementation, and I'm wondering how that happens, if my understanding above is correct. That would work too, but at a different level. -- Geoff ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] Using a Windows initilized GPK card on Linux
I am trying to use a GemPlus GPK 16 card in Linux. The card has been initialized to use with Windows login and it works well with windows. (The goal is to eventually use the same card for login to any machine by using the Kerberos PKINIT to the Windows AD.) I have ccid-0.9.3 and pcsc-lite-1.2.9-beta7 running today and am trying to use them with opensc-20050306. It appears the ccid and pcsc can see the card and return the ATR, and says it is a Gemplus GPK. But it looks like the opensc-tool, pkcs11-tool and pkcs15-tool don't know what the file structure has be written to the card by the windows initialization. failing in libopensc/card.c:756. sc_select_file: returning with: file not found. Any ideas? -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
