Re: [opensc-devel] Interfacing eToken Pro/OpenSC with Apple Keychain
Harsh Sangal a écrit : I willl have to write a tokend for my crypto USB token and I have a ifdhandler for the same. But I have a question regarding the support of smart cards/tokens in MAC OS X 10.4+ as said by apple technical staff. They say- 1. open up the terminal and run the "top" command to see the new process which would start. 2. When a smart card reader is plugged in, pcscd is auto lauched by the securityd. 3. When the card is inserted, securityd tries to load tokends present in /System/Library/Security/tokend directory till it finds a suitable one for the card. The above is true in case of smart card and reader but the same did not happen in case of my token which has its driver i.e. ifdhandler installed on the machine. When I inserted my token, nither pcscd nor any tokend is launched. Q:- Could you please guide me what is the problem or where I missed some thing? Hi, The above statements are true for natively supported cardreader. A list of them is avalaible here: http://www.opensc-project.org/sca/wiki/ScReader . For the others drivers, you need or not what we call the "pcscd autostartup fix". In a few words, we just force that pcscd is running all the time. For testing, you can just launch pcscd "by hand" in a Terminal.app. Then put your crypto USB token, and try a pcsctest in a Terminal. By this you can simply test, that all the chain (token, ifhandler, pcscd) is working. For a long term fix, you can look at http://www.opensc-project.org/sca/browser/trunk/pcscd_autostart/ to get some ideas. Cheers, Jean-Pierre Q:- I have to test the tokend with my token but directly calling it from the terminal is also giving error that "invalid arguments passed to tokend". Can we directly run the tokend from the terminal or it would only work when called by the securityd? Hope to get answers and thanks in advance... -- View this message in context: http://www.nabble.com/Interfacing-eToken-Pro-OpenSC-with-Apple-Keychain-t362607.html#a4850974 Sent from the OpenSC - Dev forum at Nabble.com. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Understanding locking
Hello, I've started playing with an Aladdin eToken PRO using latest releases of openct and opensc on FreeBSD, but I'm encountering strange behaviours on concurrent accesses. I'd like to understand how locking works in opensc and if these are expected behaviours or real bugs. Single access works like a charm, no problems. First scenario: PKCS#11 lib with lock_login = true 1) start thunderbird 2) read an encrypted message (it asks user pin and decrypt the message) 3) start pkcs11-tool -I (correctly it fails) pkcs15.c:676:sc_pkcs15_bind: sc_lock() failed: Generic reader error pkcs15.c:678:sc_pkcs15_bind: returning with: Generic reader error Cryptoki version 2.11 Manufacturer OpenSC Project (www.opensc-proje Library smart card PKCS#11 API (ver 1.0) pkcs15.c:676:sc_pkcs15_bind: sc_lock() failed: Generic reader error pkcs15.c:678:sc_pkcs15_bind: returning with: Generic reader error pkcs15.c:676:sc_pkcs15_bind: sc_lock() failed: Generic reader error pkcs15.c:678:sc_pkcs15_bind: returning with: Generic reader error 4) now thunderbird cannot use the token anymore, it fails using the PKCS#11 lib and cannot decrypt the same previous message (and this doesn't seem correct to me, locking the card should avoid any compromissions from other tools trying to access it) Second scenario: PKCS#11 lib with lock_login = false 1) start thunderbird 2) read an encrypted message (it asks user pin, but fails to decrypt the message, the PKCS#11 lib is unusable) 3) pkcs11-tool works correctly and displays all the info requested After these tests on PKCS#11 lib, I tried concurrent accesses directly with pkcs15-tool. Single call to 'pkcs15-tool -D' correctly identify the card and shows the objects stored in the token, but launching two processes has the following effect: One process (correctly) fails with: %pkcs15-tool -D Failed to lock card: Generic reader error and the other with: %pkcs15-tool -D card-cardos.c:225:cardos_check_sw: p1/p2 invalid iso7816.c:129:iso7816_read_binary: returning with: Incorrect parameters in APDU card.c:439:sc_read_binary: returning with: Incorrect parameters in APDU card.c:424:sc_read_binary: sc_read_binary() failed: Incorrect parameters in APDU card-cardos.c:225:cardos_check_sw: file not found iso7816.c:458:iso7816_select_file: returning with: File not found card-cardos.c:401:cardos_select_file: returning with: File not found card.c:563:sc_select_file: returning with: File not found pkcs15-postecert.c:336:sc_pkcs15emu_postecert_init: Failed to initialize Postecert and Cnipa emulation: Unsupported card card-cardos.c:225:cardos_check_sw: file not found iso7816.c:458:iso7816_select_file: returning with: File not found card-cardos.c:401:cardos_select_file: returning with: File not found card.c:563:sc_select_file: returning with: File not found card-cardos.c:225:cardos_check_sw: file not found iso7816.c:463:iso7816_select_file: returning with: File not found card-cardos.c:401:cardos_select_file: returning with: File not found card.c:563:sc_select_file: returning with: File not found pkcs15.c:711:sc_pkcs15_bind: returning with: Unsupported card PKCS#15 initialization failed: Unsupported card Again, this doesn't seem right to me. From what I could see, locking the card avoid other applications from using the card, but when they try to do it, even the application owning the lock begins to fails. The second scenario spotted another problem, since the single thunderbird application fails. -- Alessandro ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] more cryptoflex atr / use atr mask
Hello, On 12/06/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote: this patch adds two new ATR to the cryptoflex driver and uses the atr mask to ignore the content of the last two bytes. maybe we should do that for all cards? I improved my ATR_analysis program (available from [1]) to also parse the historical bytes of the ATR. In the case of the Cryptoflex I have: ATR: 3B 95 94 40 FF 63 01 01 02 01 + TS = 3B --> Direct Convention + T0 = 95, Y(1): 1001, K: 5 (historical bytes) TA(1) = 94 --> Fi=512, Di=8, 64.000 cycles/ETU TD(1) = 40 --> Y(i+1) = 0100, Protocol T = 0 - TC(2) = FF --> Work waiting time: 960 x 255 x (Fi/F) + Historical bytes: 63 01 01 02 01 Category indicator byte: 63 (proprietary format) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 95 94 40 FF 63 01 01 02 01 Schlumberger Cryptoflex 16Ko For a GemSafeXpresso I have: ATR: 3B 7D 94 00 00 80 31 80 65 B0 83 01 01 90 83 00 90 00 + TS = 3B --> Direct Convention + T0 = 7D, Y(1): 0111, K: 13 (historical bytes) TA(1) = 94 --> Fi=512, Di=8, 64.000 cycles/ETU TB(1) = 00 --> Programming Param P: 0 Volts, I: 0 milliamperes TC(1) = 00 --> Extra guard time: 0 + Historical bytes: 80 31 80 65 B0 83 01 01 90 83 00 90 00 Category indicator byte: 80 (compact TLV data object) Tag: 3, len: 1 (card service data byte) Card service data byte: 80 - Application selection: by full DF name - EF.DIR and EF.ATR access services: by GET RECORD(s) command - Card with MF Tag: 6, len: 5 (pre-issuing data) Data: B0 83 01 01 90 Tag: 8, len: 3 (status indicator) LCS (life card cycle): 00 (No information given) SW: 9000 (Normal processing.) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 7D 94 00 00 80 31 80 65 B0 83 01 01 90 83 00 90 00 GemSafeXpresso 16k R3.2 So that last two bytes are proprietary for a cryptoflex (and may be the firmware version). But the two last bytes are NOT the firmware version for a GemSafeXpresso. if anyone knows the older cryptoflex cards: did they also have the firmware version in the last two atr bytes? if so can we ignore those bytes? Ignoring the two last bytes should be done on a case by case basis only. feedback on this patch - whether to apply or even use the atr mask for all atr entries - is very welcome. I don't think it is a good idea to do that for ALL atr entries. Bye, [1] http://ludovic.rousseau.free.fr/softwares/pcsc-tools/ -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] openct: remove device guessing
Hello, On 13/06/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote: We have some ugly code in openct that guesses whether some device is serial or usb or ... I think the code is not needed, most plattforms also don't implement it. instead I modified all parts of the code to not only pass a device name, but a device type as well (i.e. "usb", "serial","pcmcia","pcmcia_block", ...). Why did you changed char *name with name = "usb:/proc/.../ to char *type, char *device with type = "usb" and name = "/proc/..."? That does not solve the problem of device type detection. Does it? Attached a patch to implement it. Feedback is very welcome. I think it doesn't break anything (except that you need to update your code and the hotplug scripts at the same time). Your patch is hard to read since you also made code reformating. No objection since I do not use OpenCT :-) Bye, -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Understanding locking
Alessandro Premoli wrote: Second scenario: PKCS#11 lib with lock_login = false 1) start thunderbird 2) read an encrypted message (it asks user pin, but fails to decrypt the message, the PKCS#11 lib is unusable) 3) pkcs11-tool works correctly and displays all the info requested Just an addition to this second scenario: pkcs11-tool -I works, but a pkcs11-tool -s fails with the following errors: %pkcs11-tool -s -l Please enter User PIN: Using signature algorithm RSA-X-509 hello card-cardos.c:800:cardos_compute_signature: returning with: Internal error sec.c:53:sc_compute_signature: returning with: Internal error pkcs15-sec.c:331:sc_pkcs15_compute_signature: sc_compute_signature() failed: Internal error error: PKCS11 function C_SignFinal failed: rv = CKR_GENERAL_ERROR (0x5) Aborting. So it seems that crypto functions don't work at all with lock_login = false. -- Alessandro ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] PKCS11 Data Object Creation
Just wondering... does the OpenSC pkcs11 library contain functions for data object creation? I looked through the framework-pkcs15.c file (which is used by pkcs11-object.c to create objects) and found that the only supported classes are CKO_PRIVATE_KEY, CKO_PUBLIC_KEY, and CKO_CERTIFICATE. I'm working on a project that stores objects of the CKO_DATA class, so the above 3 do not cover what I need. Are there any pointers on how to implement this, if it has not been already? Thanks. -- Thomas Harning @ Identity Alliance ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Writing an openct ifd handler for librfid
On Wed, May 31, 2006 at 08:29:56AM +0200, Ludovic Rousseau wrote: > Hello, > > On 30/05/06, Henryk Plötz <[EMAIL PROTECTED]> wrote: > >I'm currently in the process of trying to write an ifd handler to be > >able to use librfid in openct (and therefore in opensc and pc/sc) to be > >run with the librfid that uses a patched openct ccid ifd handler that > >offers the ESCAPE protocol. (E.g. I'm talking about a cardman 5121 > >here.) > > [...] > > >The current way of having an openct ifd handler calling a library that > >calls another openct ifd handler seems to be ugly. For the future it > >would be nice to have the contact-less support in the same ifd as the > >contact-based part, e.g. as an additional slot (or even several slots, > >because I've been told that 4 cards should be possible). This would > >also nicely solve hotplug. Of course the most easy way would be to > >subclass the ccid handler, if there was something like subclassing in C. > > I don't have a Cardman 5121 so what I write may not apply to the Cardman 5121. > > The SCM Micro SCR 331-DI and the SCM Micro SDI 010 are contact + > contactless readers. They are seen a one reader with two slots under > pcsc-lite with my CCID driver [1]. The contactless slot uses normal > APDU and the reader firmware manages T=CL (or whatever it is) itself. Yes, thats one (I think extremely limited) layer of abtstraction which is done in some readers. Basically you have readers where the 14443-1234 implementation resides completely in firmware (such as Integrated Engineering), readers where some bits are in firmware and others on the host (such as Philips Mifare Pegoda RD-700) and readers where the whole stack resides on the host (such as Omnikey cm5121). I personally preferr 'stupid' readers since it gives more flexibility to the driver. You can talk to i-code, mifare, 14443-4(T=CL), 15693, etc. - you can activate multiple cards, you can do whatever you want. Readers with firmware protocol implementations are all limited to some subset of the theoretical functionality that a contactless 13.56MHz reader offers. librfid IMHO has to stay independent of openct, exactly for this reason. OpenCT is nice for anything that resembles traditional smartcard operation (e.g. operating a single 14443-4 compliant card in one virtual slot). But for anything more RFID related (and less smartcard related), OpenCT is not a good choice. > The OmniKey CardMan 5125 is also a dual interface reader and is > reported as "should work" with my CCID driver. But I didn't tested it > myself and do not remember if the contactless interface is also > available from my CCID driver. the 'should work' refers to the contact based part of the reader. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpgenlGptVdv.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Writing an openct ifd handler for librfid
On Tue, May 30, 2006 at 06:59:26PM +0200, Henryk Plötz wrote: > Also the build process is currently somewhat complicated because a > librfid ifd handler needs to have librfid, but librfid needs openct a > part of which is the librfid ifd handler. Some way to decouple these > dependencies? (E.g. dynamically loadable ifd handlers like for > pcsc-lite). that indeed poses some room for problems, yes. > The current way of having an openct ifd handler calling a library that > calls another openct ifd handler seems to be ugly. For the future it > would be nice to have the contact-less support in the same ifd as the > contact-based part, e.g. as an additional slot (or even several slots, > because I've been told that 4 cards should be possible). This would > also nicely solve hotplug. Of course the most easy way would be to > subclass the ccid handler, if there was something like subclassing in C. yes, I don't really like that architecture, too - but it was the easiest I could come up with, mainly because of the peculiar architecture of the cm5121, and because I didn't want to hack all the RFID stack into the ifd-ccid, which is clearly not where it belongs. Also, thinking of other readers such as Philips Pegoda, the API / abstraction layer split is again at some other point. Here we have a reader that is purely contactless, and therefore has no relation to CCID whatsoever. In that case librfid would (not yet there, but on my way) provide its own hardware-specific driver that in turn resembles a rfid_asic_transport, on which the rfid_asic_rc632 layer and the rest resides. So I guess nobody will be able to give you the answers you need. Just go forward with it and come up with anwers. If it was _that_ easy, somebody else would have done it before you ;) Thanks for your time, -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpQQVaR7Ow2w.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] cryptoshop.com?
On Tue, Jun 13, 2006 at 09:58:16PM +0200, Andreas Jellinghaus wrote: > Hi, > > has anyone bought cards from cryptoshop.com and can say > anything about their handling etc? I've mostly bought readers from them so far, but also some cards. The handling was very good. During my last trip to Vienna, I even visited them in person to pick up my most recent order. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpJfsfTrKUJU.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] PKCS#11 PIN Handling
Hi again, I've been trying to work some kinks out of the Muscle Plugin and have found that the PKCS11 library is having issues with things. I'm trying to make sure that I get the PIN number and verify before operations, so I have the plugin select a file and authenticate to it as per the examples in other pkcs15-init card implementations (such as cryptoflex). However... the authentication fails w/ P11 because P11 uses a separate PIN system (pkcs11-tool logs into the card w/ the -l flag)... when key generation is further along, it needs to create the PrKF file... it uses the sc_pkcs15init_authenticate call to check w/ the file for authentication... but since there are no PIN callbacks and the keycache is disabled, the authentication fails. Here's a short rundown of what happens: Me -> executes: pkcs11-tool -l -k rsa:1024 pkcs11-tool: Validates my PIN to the card Begins key generation process p11 library: ... muscle-plugin: looks up the path for the key authenticates to that path -- fails because no cached key data and no PIN callbacks (recent modification ignores the return value since if the user really wasn't authenticated, the key generation itself would fail) key is generated public key is extracted PrKDF entry begins updating -- after the PrKF file is encoded within sc_pkcs15init_update_any_df The PrKF file update begins... the file selection returns SC_ERROR_FILE_NOT_FOUND [correct] file creation begins... parent is selected successfully parent is unsuccessfully authenticated to key generation aborts Thanks! -- Thomas Harning @ Identity Alliance ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Interfacing eToken Pro/OpenSC with Apple Keychain
Thanks, now it is clear to me that "pcscd" would only be auto launched for a fixed set fo tokens and not in case of ours. Does the same apply to the "tokend" for the token? Becoz I found that the security server i.e. securityd didn't start any "tokend" (e.e. CAC, BELPIC etc.) present in the /System/Library/Security/tokend/... directory as I have manually started the "pcscd" and then inserted my token. -- View this message in context: http://www.nabble.com/Interfacing-eToken-Pro-OpenSC-with-Apple-Keychain-t362607.html#a4877195 Sent from the OpenSC - Dev forum at Nabble.com. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
