[opensc-devel] ccid_set_protocol, FLAG_AUTO_ATRPARSE (dwFeatures & 0x2) handling
While trying to fix Broadcom Corp CCID build-in reader (USB ID 0A5C:5801) found Dell Latitude E6400 and others, I discovered that the device's advertised second bit (0x2) of the dwFeatures flags of USB CCID descriptor causes problems for the openct ifd-ccid.c reader driver. The driver cannot power up a card. The bit 0x2 is described in CCID USB document as "* 0002h Automatic parameter configuration based on ATR data". If I ignore that bit the ifd-ccid.c powers up the card. If I don't, the card doesn't power up. The first difference between two cases is the set parameters command: Fails with 0xFB: Req : 61 07 00 00 00 00 04 01 00 00 00 00 00 00 00 00 00 Repl: 82 07 00 00 00 00 04 40 fb 00 00 00 00 00 00 00 00 Succeeds: Req : 61 07 00 00 00 00 04 01 00 00 96 10 00 45 00 fe 00 Repl: 82 07 00 00 00 00 04 00 ff 00 96 10 00 45 00 fe 00 As you can see, the second request, which succeeds, is filled with parameters parsed from ATR, while the corresponding parameters are zeroes in the first request. Also see http://www.natisbad.org/E4300/index.html . I wonder what is the correct interpretation of the 0x02 bit of dwFeatures ? Thank you. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Online ATR parsing
The ATR parsing web app is still available at http://smartcard-atr.appspot.com/ 2009/10/25 Martin Paljak : > > > > > > This way pressing return in the ATR field submits the ATR instead of > generating a newline inside the textarea. Done. > It would be useful to also list all cards in smartcard_list.txt and maybe > even be able to browse them by some characteristics, like > http://pcsclite.alioth.debian.org/section.html. At least a listing of all > ATR-s with a link to parse page would be useful. For now I only add a link to the list in text. Thanks -- 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] [opensc-commits] svn opensc changed[3839] Remove card->finish() functions that do nothing
I think the best place to develop is trunk. It is for 0.12 release, no compatibility with 0.11.* left any more. In case we need another 0.11 release, I will create a maintainance branch from 0.11.11 release. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Nothing works any more...?!? - Kubuntu Karmic Koala [Re: APDU-Traces [OpenSC] #190: Problems with Siemens CardOS 4.3b (authentication, tokeninfo)]
2009/11/13 Douglas E. Engert : > > Douglas E. Engert wrote: >> >> Marc Wäckerlin wrote: >> >>> Unfortunately: Now that I have the time, it does not work >>> anymore! Perhaps it has something to do with my upgrade to >>> Ubuntu 09.10 Karmic Koala? The OpenSC module (onepin-) >>> opensc-pkcs11.so does no more show the real slots, but about >>> 16 useless "Virtual Slots"! >>> >>> What's the problem? >>> >> >> Is pcscd running? if not try starting it with >> /usr/sbin/pcscd -d -f >> >> Is hald running? > > > More on this, it looks like pcscd is starting before hald > has gotten far enough along. Adding a sleep 5 to the /etc/init.d/pcscd script > appears to be a temporary circumvention. > > Also see > http://ubuntuforums.org/showthread.php?t=1323111 See also https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/475821 I don't know yet how to tell upstart (init script launcher on Ubuntu) to start pcscd _after_ HAL. Any Ubuntu expert on this list? 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] Nothing works any more...?!? - Kubuntu Karmic Koala [Re: APDU-Traces [OpenSC] #190: Problems with Siemens CardOS 4.3b (authentication, tokeninfo)]
Douglas E. Engert wrote: > > Marc Wäckerlin wrote: > >> Unfortunately: Now that I have the time, it does not work >> anymore! Perhaps it has something to do with my upgrade to >> Ubuntu 09.10 Karmic Koala? The OpenSC module (onepin-) >> opensc-pkcs11.so does no more show the real slots, but about >> 16 useless "Virtual Slots"! >> >> What's the problem? >> > > Is pcscd running? if not try starting it with > /usr/sbin/pcscd -d -f > > Is hald running? More on this, it looks like pcscd is starting before hald has gotten far enough along. Adding a sleep 5 to the /etc/init.d/pcscd script appears to be a temporary circumvention. Also see http://ubuntuforums.org/showthread.php?t=1323111 > > >>> create all log files from that single run - opensc, >>> pkcs11-spy, pcscd, your tool), so we can switch back and >>> forth to see what is wrong. >>> >>> read data works as far as I know, so please no log files >>> for that. (or what is the issue with that?) >> OpenSC does not get the full information and data differs to >> what's reported by the libsiecap11.so, so that's the reason >> for that trace. But it's a less important issue. >> >> >> Thanks, regards >> Marc Wäckerlin > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Some more feedback (0.11.11)
On 13.11.2009, at 17:52, Mats Andersson wrote:
> In apdu.c, isn’t it more accurate to use card->max_send_size to chunk packets
> when doing chaining?
> 546c546
> < if (len > card->max_send_size) {
> ---
> > if (len > 255) {
> 553c553
> < plen = card->max_send_size;
> ---
> > plen = 255;
Please send unified diffs (diff -u)
> Related to this, it might be useful to be able to set the max_send_size of a
> card/driver in the config.
It would be a bug in the card driver if it is required but not set by the
driver, wouldn't it?
> I saw one of the comments in card-incrypto34.c; “andreas says: hm, my card
> only works for small payloads”. I don’t have one of those cards, however, I
> have another (unrelated?) java-card which happens to have an applet which
> accepts the exact same APDUs for set_security_env/ restore_security_env. It
> also happens that this card only works with max_send_size == 128 together
> with SC_APDU_FLAGS_CHAINING when for example doing decipher (with the patch
> above applied). It might be something to look into if there are issues with
> this driver?
What applet is it? Is it supported by some OpenSC card driver or emulation code?
> Yet another smallish note, in framework-pkcs15.c:831 and forward. I’m not
> entirely sure of what the hack is supposed to do (the name onepin suggests
> using only one/the first PIN?). Anyway, if there are indeed one
> SC_PKCS15_PIN_FLAG_UNBLOCKING_PIN flagged pin and it comes BEFORE the
> “normal” pin (the order is of course “random” in the sense that it depends on
> how the auth contents was written), the hack_enabled wont work since
> auth_count == 1 and continue will just exit the for-loop in that case.
It is an ugly hack that is somewhat required for at least some EU eID cards and
Firefox/NSS, which just don't play together nicely if the PKCS#11 module
exports all pins and keys on the card. So it also depends on the emulated
format, which sets the authentication key to be the first in the layout.
It could be improved of course, as well as Firefox could be patched :)
Thanks,
--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Some more feedback (0.11.11)
Hi,
A few more small notes (bugs?):
In apdu.c, isn't it more accurate to use card->max_send_size to chunk packets
when doing chaining?
546c546
< if (len > card->max_send_size) {
---
> if (len > 255) {
553c553
< plen = card->max_send_size;
---
> plen = 255;
Related to this, it might be useful to be able to set the max_send_size of a
card/driver in the config.
I saw one of the comments in card-incrypto34.c; "andreas says: hm, my card only
works for small payloads". I don't have one of those cards, however, I have
another (unrelated?) java-card which happens to have an applet which accepts
the exact same APDUs for set_security_env/ restore_security_env. It also
happens that this card only works with max_send_size == 128 together with
SC_APDU_FLAGS_CHAINING when for example doing decipher (with the patch above
applied). It might be something to look into if there are issues with this
driver?
Yet another smallish note, in framework-pkcs15.c:831 and forward. I'm not
entirely sure of what the hack is supposed to do (the name onepin suggests
using only one/the first PIN?). Anyway, if there are indeed one
SC_PKCS15_PIN_FLAG_UNBLOCKING_PIN flagged pin and it comes BEFORE the "normal"
pin (the order is of course "random" in the sense that it depends on how the
auth contents was written), the hack_enabled wont work since auth_count == 1
and continue will just exit the for-loop in that case.
Cheers,
/Mats
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Nothing works any more...?!? - Kubuntu Karmic Koala [Re: APDU-Traces [OpenSC] #190: Problems with Siemens CardOS 4.3b (authentication, tokeninfo)]
Marc Wäckerlin wrote: > > Unfortunately: Now that I have the time, it does not work > anymore! Perhaps it has something to do with my upgrade to > Ubuntu 09.10 Karmic Koala? The OpenSC module (onepin-) > opensc-pkcs11.so does no more show the real slots, but about > 16 useless "Virtual Slots"! > > What's the problem? > Is pcscd running? if not try starting it with /usr/sbin/pcscd -d -f Is hald running? > >> create all log files from that single run - opensc, >> pkcs11-spy, pcscd, your tool), so we can switch back and >> forth to see what is wrong. >> >> read data works as far as I know, so please no log files >> for that. (or what is the issue with that?) > > OpenSC does not get the full information and data differs to > what's reported by the libsiecap11.so, so that's the reason > for that trace. But it's a less important issue. > > > Thanks, regards > Marc Wäckerlin -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
On 13.11.2009, at 16:42, Viktor TARASOV wrote: >>> Message time stamp (1 msec resolution for Windows. For Linux it's 1 sec >>> -- was not able to do better in a simple manner) . >>> >>> In the reader logs (for ex. in pcsc_transmit() of reader-pcsc.c) insert >>> the reader's name . It helps. >>> >> >> >> Do you have a patch with these changes or it is just a suggestion? >> > > Yes, it's implemented in our local version. > If no objection, I'll submit it to trunk. Feels useful, OK by me. We should be moving the 0.12 branch as trunk, but... -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
Martin Paljak wrote: > Hi Viktor > On 04.11.2009, at 14:52, Viktor TARASOV wrote: > > >> Message time stamp (1 msec resolution for Windows. For Linux it's 1 sec >> -- was not able to do better in a simple manner) . >> >> In the reader logs (for ex. in pcsc_transmit() of reader-pcsc.c) insert >> the reader's name . It helps. >> > > > Do you have a patch with these changes or it is just a suggestion? > Yes, it's implemented in our local version. If no objection, I'll submit it to trunk. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
Hi Viktor On 04.11.2009, at 14:52, Viktor TARASOV wrote: > Message time stamp (1 msec resolution for Windows. For Linux it's 1 sec > -- was not able to do better in a simple manner) . > > In the reader logs (for ex. in pcsc_transmit() of reader-pcsc.c) insert > the reader's name . It helps. Do you have a patch with these changes or it is just a suggestion? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Nothing works any more...?!? - Kubuntu Karmic Koala [Re: APDU-Traces [OpenSC] #190: Problems with Siemens CardOS 4.3b (authentication, tokeninfo)]
Am Donnerstag, 29. Oktober 2009 schrieb Andreas Jellinghaus: > a few questions about this: > == libseacap11.so: Read Data (no login) > == == libseacap11.so: Create > Certificate/Key == == libseacap11.so: > Read Data (with login) == == > libseacap11.so: Delete Certificate/Key == > == opensc-pkcs11.so: Read Data (no login) > == == opensc-pkcs11.so: Create > Certificate/Key == > > so you also want to create keys on the card? Yes, a C_CreateObject for the Certificate and private key. Means: Import a PKCS#12 file to the SmartCard. > So far I was only aware of your plans to: > * unlock cards fresh from the CA (no log file for that) No Problem for that - direct APDU-calls. > * store certificates (part of the log I hope) What's the difference between "store" and "create" certificates? For me, that's the same. Yes, in the log, labeled "create". > * delete certificates? (part of the log I hope) > * store private data objects (no log - but a "later" > issue, right?) Yes to all. > ok, will have a look and see if I can find out what is > wrong. Yes, thank's. Any results so far? > btw: an opensc debug log (level 6) for "Create > Certifikate/Key" would be nice too. > maybe best as sync'ed logs Yes, sorry, that's the reason for the delay of this answer, I was frequently interrupted by other tasks dropping in ... Unfortunately: Now that I have the time, it does not work anymore! Perhaps it has something to do with my upgrade to Ubuntu 09.10 Karmic Koala? The OpenSC module (onepin-) opensc-pkcs11.so does no more show the real slots, but about 16 useless "Virtual Slots"! What's the problem? > create all log files from that single run - opensc, > pkcs11-spy, pcscd, your tool), so we can switch back and > forth to see what is wrong. > > read data works as far as I know, so please no log files > for that. (or what is the issue with that?) OpenSC does not get the full information and data differs to what's reported by the libsiecap11.so, so that's the reason for that trace. But it's a less important issue. Thanks, regards Marc Wäckerlin -- SwissSign AG > extreme security & identity Pfingstweidstrasse 60b > CH - 8080 Zürich Tel: +41-58/386'24'93 > Mobil: +41-79/721'23'24 marc.waecker...@tech.swisssign.com > http://swisssign.com Secure Mailbox https://incamail.post.ch/ marc.waecker...@swisssign.com SwissSign, ein Unternehmen der Schweizerischen Post, schützt und beschleunigt Ihre Geschäftsprozesse mit einfachen Lösungen für eindeutige Identifikation, digitale Signatur und sichere Kommunikation E-Mail Richtlinien: http://marc.waeckerlin.org Bitte korrekt zitieren: mit '>' am Zeilenanfang ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15init: dissociate object ID and file index
Andreas Jellinghaus wrote: > the old mechanism for selecting IDs was maybe too simple, so implementing > a better mechanism would be a good idea. I guess the card driver should > have some control over it, as different cards have different requirements. > Yes!!! That's the point! IMHO, it's the most essential point that actually handicaps (sorry!) the OpenSC support. Card specific pkcs15init part needs more freedom. There should be the possibility to make OpenSC support of a particular card to be compatible with the card producer's native middleware . Actually, there is an emulation of 'pkcs15' -- it's quiet natural to have the possibility to emulate 'pkcs15init' (or at least to support non-pkcs15 content descriptors). > for example: > * with some cards, file index must be uniq (e.g. you can't have foo/A and > bar/A) > * some cards might want to set short ids (one byte global values for direct > reference) > * some cards might be limited - at least some special objects need to have > a "right" file ID. > > no idea how to actually implement it. if it breaks some or all cards, > now is a good time to make big changes, as we break ABI anyway. > It should not break the other's card support. IMHO, it can be done absolutely transparently. The sc_pkcs15init_operations has to be extended by some limited number of methods like: get_free_index() -- card specific file index policy; store_data() -- to update non-pkcs15 descriptor system; update_df() -- to support complete emulation of pkcs15init (without on-card PKCS#15 file system); change_attr() -- update non-pkcs15; no more need of select_id(): the general support of intrinsic IDs should be sufficient. maybe a couple more ... It can be done gradually. Each card will decide itself what to implement, in the same manner as it's actually done . > opensc reads all DF files on startup, so if a new ID is needed, a card > driver could (worst case) go through all DF entries and see which ones > are already in use to avoid conflicts? > IMHO, for the crypto objects the ID should be an intrinsic one. Any way, card (or, if you like, the on-card pkcs15 application) should not contain the same object twice. So, no danger of ID collision. The same for the DATA object, some unique ID can be derived from it's content and attributes. In any case file index should not be derived from ID. > Regards, Andrea Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Small patch to improve wesctos pkcs15init
François Leblanc a écrit : >> Hi, >> >> If someone have few minutes to patch, (this concern westcos card only) >> >> thank you very much. >> >> François. >> > >As I have my hands in the source, I've done it. > >Cheers, > >Jean-Pierre Thank you Jean-Pierre. François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Small patch to improve wesctos pkcs15init
François Leblanc a écrit : > Hi, > > If someone have few minutes to patch, (this concern westcos card only) > > thank you very much. > > François. > > As I have my hands in the source, I've done it. Cheers, Jean-Pierre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Small patch to improve wesctos pkcs15init
Hi, If someone have few minutes to patch, (this concern westcos card only) thank you very much. François. westcos-improve-pkcs15init.patch Description: westcos-improve-pkcs15init.patch ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
