Re: [opensc-devel] PIN not sent to card before signing
On Thursday 25. October 2012 09:13:58 Douglas E. Engert wrote: [...] Oct 24 16:35:41 off17 pcscd[4490]: 0477 APDU: 00 2A 9E 9A 80 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 24 16:35:41 off17 pcscd[4490]: 00048524 SW: 67 00 Actually here is the problem. The above 67 00 is wrong length. The card-cardos.c tried this: 0xb721d900 16:35:41.223 [opensc-pkcs11] card-cardos.c:836:cardos_compute_signature: trying RSA_PURE_SIG (padded DigestInfo) but it failed, so it tries again: 0xb721d900 16:35:41.272 [opensc-pkcs11] card-cardos.c:842:cardos_compute_signature: trying RSA_SIG (just the DigestInfo) Oct 24 16:35:41 off17 pcscd[4490]: 0378 APDU: 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 24 16:35:41 off17 pcscd[4490]: 00023629 SW: 69 82 The 69 82 is Command not allowed, Security Status not satisfied (i.e. user_consent) The question is why does it try the padded DigestInfo first? See the comments in card-cardos.c at line 821. If the right FLAGS are set, it should get it right the first time. You are right! Reselecting the signature DF keeps the security status active (I tried it). I looked at the source code of the corresponding part (card- cardos.c, line 821), and the commentary gives it away: /* XXX As we don't know what operations are allowed with a * certain key, let's try RSA_PURE etc. and see which operation * succeeds (this is not really beautiful, but currently the * only way I see) -- Nils * * We also check for several caps flags here to pervent generating * invalid signatures with duplicated hash prefixes with some cards */ This is wrong. You can read those informations from the supportedAlgorithms sequence in the TokenInfo file (I have to lines there with RSA_PKCS and SHA1_RSA_PKCS as mechanisms and both with RSA2_SIG for the algorithm (which is also the algorithm of the key)). There are 4 other pkcs15-*.c modules that use the card-cardos.c driver. It looks like your card is not one of them. This is were others on the list with CardOS cards could help. I don't understand that. Do you mean, that it selects the wrong card driver? I have manually created the PKCS#15 application to reference a seperate signature application. There are 4 pkcs15 emulation modules that appear to use the card-cardos.c driver, pkcs15-aactalis.c, pkcs15-infocamere.c, pkcs15-postecert.c, and pkcs15-tccardos. The PKCS15 emulation modules help fill in some of the details. The setting of the SC_CARD_CAP_ONLY_* flags used in card-cardos.c, are set in pkcs15.c in a fix_starcos-pkcs15-card(), and maybe a similar response to the type of problem you are seeing. (but not a generic fix, if the flags can be derived form some information on the card.) I don't have any CardOS cards or experience with them but others on this list do, and they should respond. What might be the issue is CardOS is not a true PKCS15 card, or does not store all the FLAGS that are required, or none of the previous cards supported user_consent, or user_consent was never set on and keys on these cards. I see the problem, but without any CardOS cards, don't know the best way to fix it. I have written a patch, which uses the algorithm information which is stored in the TokenInfo file of PKCS#15, and issued a pull request for it: https://github.com/OpenSC/OpenSC/pull/97 cheers Mathias ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to identify a smartcard reader serial number
Hi! lsusb -v shows the field 'iSerial'. I have some readers which use '0' for this field, which means they don't include a serial number. A value bigger than 0 is the index to the USB string, which contains the actual serial number. You could try to use a hash of the full USB descriptor as identifier. This works if readers of the same type differ in some fields. However, I don't know if this will always work for any kind of reader family. Cheers, Frank. On Friday, November 09 at 09:38AM, Jean-Michel Pouré - GOOZE wrote: Dear all, Simple question as usual. Readers with smartcards have a serial number, i.e.: opensc-tool --serial Using reader with a card: Feitian ePass2003 01 00 68 35 10 17 17 05 12 01 h5.. But do smartcard readers without smartcard have serial numbers? Running lsusb -v on hardware, I don't see any serial number for each smartcard reader connected to a USB hub. The reason for the question is that I would like to build a 8x8 smartcard readers bench when readers are numbered from 1 to 64. The bench could be used for testing or mass initialization. How to identify a smartcard reader plugged using USB BEFORE a smartcard is inserted in the reader? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACEhttp://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc pgpjNOwSt4RA1.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] How to identify a smartcard reader serial number
Dear all, lsusb -v shows the field 'iSerial'. I have some readers which use '0' for this field, which means they don't include a serial number. A value bigger than 0 is the index to the USB string, which contains the actual serial number. Thank you Frank and others for your answers. You could try to use a hash of the full USB descriptor as identifier. This works if readers of the same type differ in some fields. However, I don't know if this will always work for any kind of reader family. I understand that iSerial is usually set to zero. If we mix all kind of hardware, a value of zero will be more frequent. Anyway our hardware has a value set to zero and we don't plan to buy new hardware. And we should be able to test and add any kind of hardware. Initially, I was planning to use the same bench for OpenSC regression testing and initialization, but this is nonsense. Smartcards can be initialized using a smartcard printer. Tokens should be initialized one-by-one. Maybe using a cheap robot. Regression testing is a different process: For OpenSC regression testing, I am moving towards a farm with KVM virtual systems running. One the one side there should be virtual systems. On the other side a bench with 64 readers with cards inserted and tokens plugged-in. The bench should be flexible enough to test several systems (Windows XP, Vista, 7 and 8) and variations (SP1, SP2, etc ...) and recent GNU/Linux systems, deb or RPM variations. USBip can be used as a glue to serve the readers to the system. To simplify everything: * There should be only one virtual system running at a time. * Each system should be connecting to one remote smartcard only. After booting the bench running Debian GNU/Linux, we can use a virtual guest OS to identify each device: First, we list all available devices: usbip -l 10.8.0.100 (address of bench) Then we attach each devices, query the reader and detach it. opensc-tool -l returns the name of the smartcard reader. opensc-tool --serial allows to identify the smartcard/token inserted. As there is only ONE usb device connected at time, there should be no conflict. Everytime a device is plugged-in, we need to run discovery again. The result is written to a text file and served to the farm using Apache. If you think of a more simple solution, please advise. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SmartCard-HSM Tool with key wrap / unwrap
Good evening, we've created a pull request towards OpenSC/staging for adding the SmartCard-HSM tool (sc-hsm-tool). Using version 0.17 or higher, the SmartCard-HSM provides for a key wrap / unwrap mechanism that allows to securely export and import card generated keys. Key values are encrypted under a 256-bit AES Device Key Encryption Key (DKEK) and saved to file with key description and optional certificate. From such a file, the key can be recreated in a SmartCard-HSM that has been set-up with the same DKEK. Using this mechanism, one can securely backup keys or migrate keys between different SmartCard-HSMs. This increases the capacity of the device, as infrequently used keys can be exported and archived externally. It also provides for redundancy and load balancing if keys are replicated in a cluster of SmartCard-HSMs. The DKEK can be recreated from a defined number of key shares. Such key shares are created with sc-hsm-tool and saved to file using password based encryption. Kind regards, Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] openpgp.profile missing from win32 nightlies
The latest nightlies from https://www.opensc-project.org/downloads/nightly/staging/win32/ do not come with openpgp.profile. Is it deliberate or a bug in the installer? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
