Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 168942 - app-crypt/ccid does not work with omnikey 6121 reader
Summary: app-crypt/ccid does not work with omnikey 6121 reader
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Crypto team [DISABLED]
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-01 22:25 UTC by Radko Lazarov
Modified: 2007-03-09 14:41 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
non working pcsc-lite-1.4.0 (config.log,108.88 KB, text/plain)
2007-03-03 13:44 UTC, Radko Lazarov
Details
non working ccid-1.2.1 (config.log,95.20 KB, text/plain)
2007-03-03 13:45 UTC, Radko Lazarov
Details
pcscd debug , non working , compiled with configure log files attached for non working combination (pcscd.debug,220.28 KB, text/plain)
2007-03-03 14:06 UTC, Radko Lazarov
Details
working driver /ccid/ provided by OmniKey (ifdokccid_lnx-3.0.0.tar.gz,135.97 KB, text/plain)
2007-03-03 17:11 UTC, Radko Lazarov
Details
sudo ./src/parse > output (output,3.85 KB, text/plain)
2007-03-03 22:15 UTC, Radko Lazarov
Details
debug with ccid on the site where working (pcscd_ccid_driver_site1_work.log,219.13 KB, text/plain)
2007-03-03 22:26 UTC, Radko Lazarov
Details
debug with ccid on the site where doesn't work (pcscd_ccid_driver_site2_not_work.log,223.07 KB, text/plain)
2007-03-03 22:27 UTC, Radko Lazarov
Details
debug with OmniKey on the site1 working (pcscd_omnikey_driver_site1_work.log,198.72 KB, text/plain)
2007-03-03 22:27 UTC, Radko Lazarov
Details
debug with OmniKey on the site2 working (pcscd_omnikey_driver_site2_work.log,192.46 KB, text/plain)
2007-03-03 22:28 UTC, Radko Lazarov
Details
ccid patched sit1 working (pcscd.ccid_patched_site1_working,219.35 KB, text/plain)
2007-03-04 19:51 UTC, Radko Lazarov
Details
ccid patched site2 doesn't work (pcscd.ccid_patched_site2_not_working,222.15 KB, text/plain)
2007-03-04 19:51 UTC, Radko Lazarov
Details
ccid not patched for comparison (ccid.debug,223.02 KB, text/plain)
2007-03-04 22:54 UTC, Radko Lazarov
Details
ccid_patched for comparison (ccid_patched.debug,221.62 KB, text/plain)
2007-03-04 22:55 UTC, Radko Lazarov
Details
omnikey debug for comparison (omni.debug,197.60 KB, text/plain)
2007-03-04 22:55 UTC, Radko Lazarov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Radko Lazarov 2007-03-01 22:25:07 UTC
compiling pcsc-lite-1.4.0  even older and ccid-1.2.1
with emerge pscs-lite ccid
makes them ok, but I cannot login into one site require certificate atuhorization.
that certificate is located on the card. So all certificates are visible but when it try to read it and to use it the error returneed is:

Error establishing  an encrypted connection to XXXX Error Code - 12222
.

and form pcscd debug i got:

commands.c :1039:CmdXfrBlockTPDU_T0() Command too long (266 bytes) for max: 261 bytes
ifdwrapper.c:735:IFDTransmit() Card not transacted: 612
winscard.c:1481:SCardTransmit() Card not transacted: 0x80100016


If I tar zxf pcsc-lite and ccid packages form /usr/portage/distfiles and compile them wiht: configure , make , make install
everything is working!

so sowmthing with configure options brakes the package and it doesn't work in some cases.

I did another test  I tried to complie packages in the way emerge use it:
so I tried following configure options for pcsc-lite

configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable
-usbdropdir=/usr/lib/readers/usb --enable-muscledropdir=/usr/share/pcsc/services --enable-runpid=/var/run/pcscd.pid --disable-debug --disable-static --build=i686-pc-linux-
gnu

configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-usbdropdir=/usr/lib/read
ers/usb --enable-muscledropdir=/usr/share/pcsc/services --enable-runpid=/var/run/pcscd.pid --disable-debug --disable-static

configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-usbdropdir=/usr/lib/readers/usb --enable-muscledropdir=/usr/share/pcsc/services --enable-runpid=/var/run/pcscd.pid

and for ccid:

configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable
-udev --disable-twinserial --build=i686-pc-linux-gnu

configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-udev --disable-twinseria
l

configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-ude

but again it failed to use certificate.

the only combination that works in my case is:

for pcsc-lite

configure
make 
make install

ten for ccid:
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --enable-udev
or
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure
make
make install


so in that way everything is ok.

could you help to find that issue?






Reproducible: Always
Comment 1 Alon Bar-Lev (RETIRED) gentoo-dev 2007-03-02 05:41:43 UTC
This is strange!
Can you please attach config.log of working pcsc-lite configure and none working pcsc-lite configure?
Thanks!
Comment 2 Alon Bar-Lev (RETIRED) gentoo-dev 2007-03-02 05:54:31 UTC
Do you sure that both components are not working?
For example, have you tried manually compiled ccid with emerge version of pcsc-lite?
Comment 3 Alon Bar-Lev (RETIRED) gentoo-dev 2007-03-02 07:56:16 UTC
I diffed my config.log, I don't see any difference except of directory names in both versions.

pcsc-lite:
configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--enable-usbdropdir=/usr/lib/readers/usb
--enable-muscledropdir=/usr/share/pcsc/services
--enable-runpid=/var/run/pcscd.pid

ccid:
configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-udev

The only thing that is none default and may do something is the --enable-udev on the ccid... Can you please try to remove it and compile it again...?

If it still does not work, there is a trigger of hotplug which was recently added to pcsc-lite, try to remove the --enable-runpid from pcsc-lite.

I am sorry to make you work so hard... but I cannot reproduce this issue :)
Thanks!
Comment 4 Ludovic Rousseau 2007-03-02 15:01:50 UTC
I would need some more information:
- the name of the card reader you use
- the ATR of the card
- the APDU causing the problem (you can use pcscd --foreground --debug --apdu to display the APDUs)
Comment 5 Radko Lazarov 2007-03-03 13:44:40 UTC
Created attachment 111909 [details]
non working pcsc-lite-1.4.0
Comment 6 Radko Lazarov 2007-03-03 13:45:10 UTC
Created attachment 111910 [details]
non working ccid-1.2.1
Comment 7 Radko Lazarov 2007-03-03 13:46:02 UTC
Comment on attachment 111909 [details]
non working pcsc-lite-1.4.0

without --enable-runpid,
so it's not the problem in that case
Comment 8 Radko Lazarov 2007-03-03 13:52:48 UTC
(In reply to comment #2)
> Do you sure that both components are not working?
> For example, have you tried manually compiled ccid with emerge version of
> pcsc-lite?
> 

Hi,

I suppose the problem is in pcsc-lite, since we got Command too long in it's debug but I'm not sure, anyway the case is that we use combination of pcsc-lite and ccid. I do not think there are problems in both of them but how to find it out.

no I did not try combination between emerged and non emerged, because If I have to use one emerged I have to modify the directory options on the configure of second one otherwise the pcsc-lite will not find ccid and vice-versa.

I do not think it worth the efforts since I have compiled both of the in the way emerge do it, I mean with the same configure options and it doesn't work.

Important is that the problem is not for all certificates I have on the card, I'm able to login on one site with one certificate but not on the other with other certificate, so the problem is not general one.
Comment 9 Radko Lazarov 2007-03-03 13:57:07 UTC
(In reply to comment #3)
> I diffed my config.log, I don't see any difference except of directory names in
> both versions.
> 
> pcsc-lite:
> configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
> --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
> --enable-usbdropdir=/usr/lib/readers/usb
> --enable-muscledropdir=/usr/share/pcsc/services
> --enable-runpid=/var/run/pcscd.pid
> 
> ccid:
> configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
> --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-udev
> 
> The only thing that is none default and may do something is the --enable-udev
> on the ccid... Can you please try to remove it and compile it again...?
> 
> If it still does not work, there is a trigger of hotplug which was recently
> added to pcsc-lite, try to remove the --enable-runpid from pcsc-lite.
> 
> I am sorry to make you work so hard... but I cannot reproduce this issue :)
> Thanks!
> 

About --enable-udev on ccid, yes I have tried it but it doens't matter because it goes enabled by default of configure ;-), so it's not the problem, more likely the case is in pcsc-lite but we have to prove it.

As I write you a post before, I tried without --enable-runpid but again doesn't work.

Do not worry I want to clarify and to have the problem fixed, so I'll be able to use even emerged version, otherwise I have to compile manually and to be careful with configure options. The only problem is I have no much time and could take a while before did all possible tests.

Comment 10 Radko Lazarov 2007-03-03 14:05:15 UTC
(In reply to comment #4)
> I would need some more information:
> - the name of the card reader you use
> - the ATR of the card
> - the APDU causing the problem (you can use pcscd --foreground --debug --apdu
> to display the APDUs)
> 

Hello Ludovic,

thank you again you are trying to help me.

Please find attached the required pcscd debug with options suggested by you.

OmniKey CardMan 6121

Card ATR: 3B F2 18 00 02 C1 0A 31 FE 58 C8 08 74

But you can see them in debug log file
Comment 11 Radko Lazarov 2007-03-03 14:06:47 UTC
Created attachment 111920 [details]
pcscd debug , non working , compiled with configure log files attached for non working combination
Comment 12 Radko Lazarov 2007-03-03 14:20:11 UTC
Just tried pcsc-lite configured with configure options provided by emerge:
configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-usbdropdir=/usr/lib/readers/usb --enable-muscledropdir=/usr/share/pcsc/services --enable-runpid=/var/run/pcscd.pid --disable-debug --disable-static --build=i686-pc-linux-gnu

and ccid wihtout options, soory I lied you about udev, by default it is deiabled.

so after test it doesn't work, I'll try the opposite now the check it.
Comment 13 Radko Lazarov 2007-03-03 15:43:27 UTC
Just tried the opposite combination:
pcsc-lite without options to configure and
ccid with: 
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-twinserial --build=i686-pc-linux-gnu --enable-udev


again it doens;t work, very interesting indeed.
Comment 14 Radko Lazarov 2007-03-03 16:15:25 UTC
I do not know what happened but it stopped working even with both compiled with just configure...  something is wrong on my system or whatever I'm going to find it out.....really strange .. it was working few days before seems I've changed something after so many different tests!
Comment 15 Radko Lazarov 2007-03-03 17:11:44 UTC
Created attachment 111948 [details]
working driver /ccid/ provided by OmniKey
Comment 16 Radko Lazarov 2007-03-03 18:07:39 UTC
Hello ,

I found it!
It's my mistake for what I want to apologize.

So there is no issue with configure options at all, it seems it was always working with the driver provided by OmiKey site /the driver attached/ instead with ccid.
I really sorry Ludovic I have misguided you a bit few months ago.

So the problem is in ccid for sure, with the ccid version I'm able to log in some sites with one certificate, but not able to log on another with diff certificate also located on the card.

If the OmniKey driver is used everything is working fine.

Ludovic I'll provide you with all the information needed to be able to fix this issue.

Today it stopped working because I found the old stuff and remove it, so I have removed the OmniKey driver because I was sure that it's not used and the card is working with ccid

So here is the explanation:

The driver provided by OmniKey I have installed months ago for which I thought I  was unsintalled is installed by default in : /usr/local/pcsc/drivers

called : ifdokccid_lnx-3.0.0.bundle

1. About gentoo emerge packages:
with configure options provided by emerge ccid should be install in:
/usr/lib/readers/usb
also this is the directory where pcscd looks for drivers, that's why it didn't work, but with default configure it was working because in that case pcscd looks for drivers in /usr/local/pcsc/drivers where it finds the driver from OmniKey.

Even when ccid is compile with default configure options it goes in the same directory sa OmniKey driver but pcscd always choose the driver from OmniKey, I do nto know how and what's the order pcscd choose the driver if there are few, sine both drivers contains OmniKey 6121 support in their Info.plist?

So the only visible diff between ccid and OmniKey driver/libralry is that OmniKey use libpthread:
elf:/tmp# ldd /usr/lib/readers/usb/ifd-ccid.bundle/Contents/Linux/libccid.so.1.2.1
              linux-gate.so.1 =>  (0xb7fac000)
            libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0xb7f76000)
            libc.so.6 => /lib/libc.so.6 (0xb7e2c000)
            /lib/ld-linux.so.2 (0x80000000)
elf:/tmp# ldd /usr/lib/readers/usb/ifdokccid_lnx-3.0.0.bundle/Contents/Linux/ifdokccid.so
            linux-gate.so.1 =>  (0xb7f15000)
            libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0xb7ee3000)
            libpthread.so.0 => /lib/libpthread.so.0 (0xb7ecc000)
            libc.so.6 => /lib/libc.so.6 (0xb7d82000)
            /lib/ld-linux.so.2 (0x80000000)

but may be it's not the case?

So the problem is with ccid:

commands.c:1091:CmdXfrBlockTPDU_T0() Command too long (266 bytes) for max: 261 bytes


The debug is attached.

I think this bug can be closed since it's not connected to the gentoo itself but it concern the ccid package.

Please advice me what to do and if needed to open new bug where to do it.

Regards 

Comment 17 Ludovic Rousseau 2007-03-03 20:12:58 UTC
Your application is sending an extended APDU but your reader says it does NOT support that.

The APDU is 00 2A 80 86 00 01 01 00 00 01 FF FF FF ...
CLA = 00
INS = 2A
P1 = 80
P2 = 86
Lc =  00 01 01 (256 bytes)
Le = 00 00 001 (1 byte)

Maybe the reader can do extended APDU but does not say so and only the proprietary driver know that.

Can you run the parse program as described in http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant and post the result?

What is the application you are using?
Comment 18 Ludovic Rousseau 2007-03-03 20:18:20 UTC
(In reply to comment #16)
> Even when ccid is compile with default configure options it goes in the same
> directory sa OmniKey driver but pcscd always choose the driver from OmniKey, I
> do nto know how and what's the order pcscd choose the driver if there are few,
> sine both drivers contains OmniKey 6121 support in their Info.plist?

Good question. I guess pcscd uses the first drver it founds working with the given reader.

> So the problem is with ccid:

Maybe not :-)

> commands.c:1091:CmdXfrBlockTPDU_T0() Command too long (266 bytes) for max: 261
> bytes
> 
> The debug is attached.

I can't find any debug attached :-(

What I need is the pcscd debug trace of the working APDU with the Omnikey driver.
It would be even better if you could log the USB frames sent/received by the Omnikey driver but I don't know how to do that.
Comment 19 Radko Lazarov 2007-03-03 22:15:04 UTC
(In reply to comment #17)
> Your application is sending an extended APDU but your reader says it does NOT
> support that.
> 
> The APDU is 00 2A 80 86 00 01 01 00 00 01 FF FF FF ...
> CLA = 00
> INS = 2A
> P1 = 80
> P2 = 86
> Lc =  00 01 01 (256 bytes)
> Le = 00 00 001 (1 byte)
> 
> Maybe the reader can do extended APDU but does not say so and only the
> proprietary driver know that.
> 
> Can you run the parse program as described in
> http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant and post the result?
> 
> What is the application you are using?
> 

Hi,

Please find attached required output.

The application is Mozilla Firefox with Siemens api for card. /check you mailbox,I'll sent it to you/

Comment 20 Radko Lazarov 2007-03-03 22:15:49 UTC
Created attachment 111979 [details]
sudo ./src/parse > output
Comment 21 Radko Lazarov 2007-03-03 22:26:05 UTC
(In reply to comment #18)
> (In reply to comment #16)
> > Even when ccid is compile with default configure options it goes in the same
> > directory sa OmniKey driver but pcscd always choose the driver from OmniKey, I
> > do nto know how and what's the order pcscd choose the driver if there are few,
> > sine both drivers contains OmniKey 6121 support in their Info.plist?
> 
> Good question. I guess pcscd uses the first drver it founds working with the
> given reader.


Interesting, but there should be some algorithm how it search so we will know which one will be first or chosen. Now we only knows it always choose OmniKey driver in my case.



> 
> > So the problem is with ccid:
> 
> Maybe not :-)


May be , but now the only difference is the driver used, I tried without changing anything just driver used, in one case works in other not, so for me most likely it's in CCID, may be it's due to reader reports misguided information!

> 
> > commands.c:1091:CmdXfrBlockTPDU_T0() Command too long (266 bytes) for max: 261
> > bytes
> > 
> > The debug is attached.
> 
> I can't find any debug attached :-(


The debug in question is the debug where you got APDU stuff ;-)

> 
> What I need is the pcscd debug trace of the working APDU with the Omnikey
> driver.
> It would be even better if you could log the USB frames sent/received by the
> Omnikey driver but I don't know how to do that.
> 

Please find attached 4 debbugs with APDU,
2 with 2 diff working site/certificates with OmniKey driver
2 with the same sites but with ccid driver, one of them works one not.

about USB stuff I have no idea how to catch it yet, if you have one I'll try to do it. I hope attached debugs with OmniKey driver will help you.

Could it be connected with the length of the certificates?
To mention also other diff between certificates:
in the case it works with both drivers there are only personal certificate on the card
in the case where it doesn't work with ccid on the card there are 2 certificate:
 - first one is certificate authority for the site
 - second one is personal certificate for the user used

I do not think this is the case, since it seems works with both driver but for 3rd site with CA and personal certificate.



Comment 22 Radko Lazarov 2007-03-03 22:26:57 UTC
Created attachment 111980 [details]
debug with ccid on the site where working
Comment 23 Radko Lazarov 2007-03-03 22:27:26 UTC
Created attachment 111982 [details]
debug with ccid on the site where doesn't work
Comment 24 Radko Lazarov 2007-03-03 22:27:58 UTC
Created attachment 111984 [details]
debug with OmniKey on the site1 working
Comment 25 Radko Lazarov 2007-03-03 22:28:24 UTC
Created attachment 111985 [details]
debug with OmniKey on the site2 working
Comment 26 Radko Lazarov 2007-03-03 22:35:29 UTC
All 4 debugs attached for site1 and site2 /working, non working/ with ccid and OmniKey driver has been generated with the following procedure:

The Card reader is plugged into USB before tests start

1. start pcscd with -d -f --apdu
2. start firefox
3. open site , log in
4. enter card pin
5. choose certificate
6. after successfull (logout)/unsuccessfull login  close firefox
7. stop pcscd

start with next test trough the same points.
Comment 27 Radko Lazarov 2007-03-03 23:03:10 UTC
The difference I can see between:
pcscd_ccid_driver_site2_not_work.log
and
pcscd_omnikey_driver_site2_work.log

seems that OmniKey driver never sent so long APDU, but that's what I can help, I even do not know what's the APDU?
Comment 28 Ludovic Rousseau 2007-03-04 13:16:18 UTC
(In reply to comment #24)
> Created an attachment (id=111984) [edit]
> debug with OmniKey on the site1 working

This log file contains the "offending" extended APDU near the end:
APDU: 00 2A 80 86 00 01 01 00 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 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 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 93 C2 3A D3 D7 98 9F BE 25 88
21 3F C2 3B A2 87 0F A7 5E 39 CC 19 33 BA 79 FE 82 70 66 94 09 D2 F8 84 99 AF 01 00

SW: 74 BC FD 69 2A C2 81 CC 14 69 5B AC 70 25 BB 59 EA D0 B3 47 3A A7 0E 40 86 4E 3E 86 B1 40 81 8B 85 F8 9F E2 02 14 CB AF 60 BD 44 1B 8B E9 D9 04 04 AB 6B 41
CA DF DE 65 86 DB F4 09 44 95 0D E5 A3 DC 5E FE 91 CA D7 6F 94 80 07 0D F0 0C 6E E6 65 C1 46 0D FB 92 0C C4 EB F5 7D 78 1F 78 66 69 6B 41 4D E0 92 D9 34 63 28 FA 7A AF 05 C9 87 4F 1E 5A 5F CB 61 97 F9 9F B5 34 A3 E7 DC FE 61 15 39 F1 76 C1
44 64 27 F5 4A 2E 81 43 89 59 E5 86 C7 FD F7 12 36 C0 E2 B6 8F CD AD B5 2B B0 96 45 50 88 EC 6A E9 3F AA 60 D5 89 FC BC F0 71 73 60 21 E7 94 A8 D2 36 67 78 0E 76 BF C1 05 3E 00 8B 23 7E DA 90 42 4B AE 0C 59 A9 BD FA 17 46 46 96 48 B4 2A 4C
51 E5 EA C4 4A 54 9B F9 0A F6 6E 08 D1 03 E2 8C 0E 62 E1 4A AE D6 54 96 D1 43 B4 09 D3 36 E0 36 28 EF FD C1 3F DC 37 91 A3 48 D5 2E 90 00


You can try to patch the ccid driver so that the extended APDU mode is used.
Index: src/commands.c
===================================================================
--- src/commands.c  (révision 2454)
+++ src/commands.c  (copie de travail)
@@ -778,10 +778,6 @@ RESPONSECODE CmdXfrBlock(unsigned int re
            break;

        case CCID_CLASS_SHORT_APDU:
-           return_value = CmdXfrBlockTPDU_T0(reader_index,
-               tx_length, tx_buffer, rx_length, rx_buffer);
-           break;
-
        case CCID_CLASS_EXTENDED_APDU:
            return_value = CmdXfrBlockAPDU_extended(reader_index,
                tx_length, tx_buffer, rx_length, rx_buffer);


Recompile and install the libccid driver and report back if that works or not.
Comment 29 Radko Lazarov 2007-03-04 19:50:52 UTC
(In reply to comment #28)

Hi,

First I want to remind you that site1 is the site where I'm able to login and work with both drivers /OmniKey and ccid/, so If OmniKey works with extended APDU how does ccid managed to do it?

btw, what does APDU mean?
is it connected with the keys/certicifates somehow:
 - the number of certificate in the card
 - the id of certifikate
 - the size of certificate

How I can understand that extended APDU is used?

About patch proposed seems it doesn't work, but with small correction in the intervals/tabs it's working, so here is the patch I have applied:
--- src/commands.c      2007-03-04 21:30:15.000000000 +0200
+++ src/commands.c.orig 2007-03-04 21:31:14.000000000 +0200
@@ -778,10 +778,6 @@
                        break;

                case CCID_CLASS_SHORT_APDU:
-                       return_value = CmdXfrBlockTPDU_T0(reader_index,
-                               tx_length, tx_buffer, rx_length, rx_buffer);
-                       break;
-
                case CCID_CLASS_EXTENDED_APDU:
                        return_value = CmdXfrBlockAPDU_extended(reader_index,
                                tx_length, tx_buffer, rx_length, rx_buffer);

but it doesn't help, the result is that I'm still able to log into site1 but site2 doesn't work again. But the error is different this time:
winscard.c:1589:SCardTransmit() Send Protocol: T=1
APDU: 00 2A 80 86 00 01 01 00 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 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 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 7F 9F E5 D7 93 53 E1 8B 0B 8C 4C 3D 89 62 3E C9 0D 62 36 5C 01 B7 02 35 E4 0A 29 10 80 E6 42 47 85 8A A1 C9 01 00
ifdhandler.c:948:IFDHTransmitToICC() lun: 0
commands.c:881:CCID_Receive Protocol not supported
SW:
ifdwrapper.c:762:IFDTransmit() Card not transacted: 612
winscard.c:1616:SCardTransmit() Card not transacted: 0x80100016

Please find attached pcscd debugs with patched ccid from site1 working and problematic site2 doesn't work.



> (In reply to comment #24)
> > Created an attachment (id=111984) [edit]
> > debug with OmniKey on the site1 working
> 
> This log file contains the "offending" extended APDU near the end:
> APDU: 00 2A 80 86 00 01 01 00 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 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 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 93 C2 3A D3 D7 98 9F BE
> 25 88
> 21 3F C2 3B A2 87 0F A7 5E 39 CC 19 33 BA 79 FE 82 70 66 94 09 D2 F8 84 99 AF
> 01 00
> 
> SW: 74 BC FD 69 2A C2 81 CC 14 69 5B AC 70 25 BB 59 EA D0 B3 47 3A A7 0E 40 86
> 4E 3E 86 B1 40 81 8B 85 F8 9F E2 02 14 CB AF 60 BD 44 1B 8B E9 D9 04 04 AB 6B
> 41
> CA DF DE 65 86 DB F4 09 44 95 0D E5 A3 DC 5E FE 91 CA D7 6F 94 80 07 0D F0 0C
> 6E E6 65 C1 46 0D FB 92 0C C4 EB F5 7D 78 1F 78 66 69 6B 41 4D E0 92 D9 34 63
> 28 FA 7A AF 05 C9 87 4F 1E 5A 5F CB 61 97 F9 9F B5 34 A3 E7 DC FE 61 15 39 F1
> 76 C1
> 44 64 27 F5 4A 2E 81 43 89 59 E5 86 C7 FD F7 12 36 C0 E2 B6 8F CD AD B5 2B B0
> 96 45 50 88 EC 6A E9 3F AA 60 D5 89 FC BC F0 71 73 60 21 E7 94 A8 D2 36 67 78
> 0E 76 BF C1 05 3E 00 8B 23 7E DA 90 42 4B AE 0C 59 A9 BD FA 17 46 46 96 48 B4
> 2A 4C
> 51 E5 EA C4 4A 54 9B F9 0A F6 6E 08 D1 03 E2 8C 0E 62 E1 4A AE D6 54 96 D1 43
> B4 09 D3 36 E0 36 28 EF FD C1 3F DC 37 91 A3 48 D5 2E 90 00
> 
> 
> You can try to patch the ccid driver so that the extended APDU mode is used.
> Index: src/commands.c
> ===================================================================
> --- src/commands.c  (révision 2454)
> +++ src/commands.c  (copie de travail)
> @@ -778,10 +778,6 @@ RESPONSECODE CmdXfrBlock(unsigned int re
>             break;
> 
>         case CCID_CLASS_SHORT_APDU:
> -           return_value = CmdXfrBlockTPDU_T0(reader_index,
> -               tx_length, tx_buffer, rx_length, rx_buffer);
> -           break;
> -
>         case CCID_CLASS_EXTENDED_APDU:
>             return_value = CmdXfrBlockAPDU_extended(reader_index,
>                 tx_length, tx_buffer, rx_length, rx_buffer);
> 
> 
> Recompile and install the libccid driver and report back if that works or not.
> 

Comment 30 Radko Lazarov 2007-03-04 19:51:27 UTC
Created attachment 112106 [details]
ccid patched sit1 working
Comment 31 Radko Lazarov 2007-03-04 19:51:55 UTC
Created attachment 112107 [details]
ccid patched site2 doesn't work
Comment 32 Ludovic Rousseau 2007-03-04 20:43:40 UTC
(In reply to comment #29)
> First I want to remind you that site1 is the site where I'm able to login and
> work with both drivers /OmniKey and ccid/, so If OmniKey works with extended
> APDU how does ccid managed to do it?
> 
> btw, what does APDU mean?

Application Protocole Data Unit

> is it connected with the keys/certicifates somehow:
>  - the number of certificate in the card
>  - the id of certifikate
>  - the size of certificate

no, no, no.

> How I can understand that extended APDU is used?

Read standard ISO 7816-4 :-)

An normal APDU is limited to 255 bytes sent to the card and 256 bytes read from the card. An extended APDU is limited to 65535 bytes to/from the card.
So if you need to receive more than 256 bytes you need to use an extended APDU or use two (or more) APDUs.

> but it doesn't help, the result is that I'm still able to log into site1 but
> site2 doesn't work again. But the error is different this time:

I am not really surprised.

What is strange is that the two traces pcscd_omnikey_driver_site2_work.log and pcscd.ccid_patched_site2_not_working do NOT contain the same exchanges.
Just grep the APDU and SW (apdu result) using "grep ^[AS] file" and compare the two results.

Do you always generate the same traces with the same differences?

You can see that the last APDU is extended when using the CCID driver and is normal when using the proprietary driver. The proprietary driver may not support extended APDU after all but the application does NOT generate such an APDU when the proprietary driver is used. And that is VERY strange.
Comment 33 Radko Lazarov 2007-03-04 22:23:50 UTC
(In reply to comment #32)
> (In reply to comment #29)
> > First I want to remind you that site1 is the site where I'm able to login and
> > work with both drivers /OmniKey and ccid/, so If OmniKey works with extended
> > APDU how does ccid managed to do it?
> > 
> > btw, what does APDU mean?
> 
> Application Protocole Data Unit
> 
> > is it connected with the keys/certicifates somehow:
> >  - the number of certificate in the card
> >  - the id of certifikate
> >  - the size of certificate
> 
> no, no, no.
> 
> > How I can understand that extended APDU is used?
> 
> Read standard ISO 7816-4 :-)
> 
> An normal APDU is limited to 255 bytes sent to the card and 256 bytes read from
> the card. An extended APDU is limited to 65535 bytes to/from the card.
> So if you need to receive more than 256 bytes you need to use an extended APDU
> or use two (or more) APDUs.
> 



Is it possible OmniKey driver to send few APDU insted one extended?



> > but it doesn't help, the result is that I'm still able to log into site1 but
> > site2 doesn't work again. But the error is different this time:
> 
> I am not really surprised.
> 
> What is strange is that the two traces pcscd_omnikey_driver_site2_work.log and
> pcscd.ccid_patched_site2_not_working do NOT contain the same exchanges.
> Just grep the APDU and SW (apdu result) using "grep ^[AS] file" and compare the
> two results.
> 

Yes it is a bit different. I do not know how exactly it works, so I do not kwno if this is normal or not.


> Do you always generate the same traces with the same differences?
> 
> You can see that the last APDU is extended when using the CCID driver and is
> normal when using the proprietary driver. The proprietary driver may not
> support extended APDU after all but the application does NOT generate such an
> APDU when the proprietary driver is used. And that is VERY strange.
> 

Is it possible application not do to it because  the driver not support extended APDU.

I think OmniKEy driver is based on your ccid, so I think we/you can ask them what's the special with this card reader 6121, seems they have workaround.


> Do you always generate the same traces with the same differences?

what do you mean?

I tried to do the same with every test, but what happened behind I have no idea.
Do you have any idea how to generate two debugs where we can be sure they are the same. As I told you I start pcscd, start firefox, opne site, loging, enter card pin, choose the sertificate, and error or successfull longin, if i managed to log i logout then close th firefox and stop the pcscd, that's the precedure I alwyas do if you have better one let me know and I'll do it.

Even more If you want we can schedule one debug together, I mean I can run vncserver and let you watch what I do. Then we  can compile nad debug ccid to see what's wrong.


BTW, why did you tell me in your previous posting there is extended APDU for site1, since the site1 is working with both drivers?
if thre is with omnikey then it supports it!

very strange indeed.

Comment 34 Radko Lazarov 2007-03-04 22:54:07 UTC
I have generated new debugs, i tried to be more clear,
so now difference is nto so big, please have a loog at them I'm attaching them now.

(In reply to comment #32)
> (In reply to comment #29)
> > First I want to remind you that site1 is the site where I'm able to login and
> > work with both drivers /OmniKey and ccid/, so If OmniKey works with extended
> > APDU how does ccid managed to do it?
> > 
> > btw, what does APDU mean?
> 
> Application Protocole Data Unit
> 
> > is it connected with the keys/certicifates somehow:
> >  - the number of certificate in the card
> >  - the id of certifikate
> >  - the size of certificate
> 
> no, no, no.
> 
> > How I can understand that extended APDU is used?
> 
> Read standard ISO 7816-4 :-)
> 
> An normal APDU is limited to 255 bytes sent to the card and 256 bytes read from
> the card. An extended APDU is limited to 65535 bytes to/from the card.
> So if you need to receive more than 256 bytes you need to use an extended APDU
> or use two (or more) APDUs.
> 
> > but it doesn't help, the result is that I'm still able to log into site1 but
> > site2 doesn't work again. But the error is different this time:
> 
> I am not really surprised.
> 
> What is strange is that the two traces pcscd_omnikey_driver_site2_work.log and
> pcscd.ccid_patched_site2_not_working do NOT contain the same exchanges.
> Just grep the APDU and SW (apdu result) using "grep ^[AS] file" and compare the
> two results.
> 
> Do you always generate the same traces with the same differences?
> 
> You can see that the last APDU is extended when using the CCID driver and is
> normal when using the proprietary driver. The proprietary driver may not
> support extended APDU after all but the application does NOT generate such an
> APDU when the proprietary driver is used. And that is VERY strange.
> 

Comment 35 Radko Lazarov 2007-03-04 22:54:57 UTC
Created attachment 112120 [details]
ccid not patched  for comparison
Comment 36 Radko Lazarov 2007-03-04 22:55:27 UTC
Created attachment 112122 [details]
ccid_patched for comparison
Comment 37 Radko Lazarov 2007-03-04 22:55:50 UTC
Created attachment 112123 [details]
omnikey debug for comparison
Comment 38 Radko Lazarov 2007-03-04 23:58:08 UTC
sdiff -s ccid_AS ccid_patched_AS
SW: FA C7 84 04 42 D3 1B 75 22 EB C9 ED 52 77 82 6B 78 E4 40  | SW: 59 C5 13 6C EB 91 D5 C1 F3 4F BE E7 47 03 B0 E5 17 04 1A
SW: BF A1 BE A8 9B F6 34 95 90 00                             | SW: 93 6E 47 87 73 81 28 4D 90 00
SW: 76 32 81 D1 08 61 59 D4 59 3B B6 A7 97 D0 D8 01 65 29 53  | SW: E5 D8 5B 9A 80 74 91 19 55 94 2D 69 9A B6 59 2C 05 A4 C7
APDU: 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF FF FF FF F | APDU: 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF FF FF FF F
SW: A0 06 30 04 04 02 44 00 A1 06 30 04 04 02 44 01 A4 06 30  | SW:



================================================================================

sdiff -s ccid_AS omni_AS
SW: FA C7 84 04 42 D3 1B 75 22 EB C9 ED 52 77 82 6B 78 E4 40  | SW: 2D 4C 39 39 DB C5 18 5B 78 43 C7 2A 62 30 F2 42 D7 20 DB
SW: BF A1 BE A8 9B F6 34 95 90 00                             | SW: E4 9F BD AB DF 67 90 5D 90 00
SW: 76 32 81 D1 08 61 59 D4 59 3B B6 A7 97 D0 D8 01 65 29 53  | SW: E0 61 B3 8F 17 45 82 2B 7D F8 07 A0 A7 DC F8 65 3C 28 26
APDU: 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF FF FF FF F | APDU: 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF FF FF FF F
SW: A0 06 30 04 04 02 44 00 A1 06 30 04 04 02 44 01 A4 06 30  | SW: 84 0E 76 69 4D 7C 35 F1 5F 1A DE D7 F3 2F 44 7E C5 8D 58


===============================================================
sdiff -s ccid_patched_AS omni_AS
SW: 59 C5 13 6C EB 91 D5 C1 F3 4F BE E7 47 03 B0 E5 17 04 1A  | SW: 2D 4C 39 39 DB C5 18 5B 78 43 C7 2A 62 30 F2 42 D7 20 DB
SW: 93 6E 47 87 73 81 28 4D 90 00                             | SW: E4 9F BD AB DF 67 90 5D 90 00
SW: E5 D8 5B 9A 80 74 91 19 55 94 2D 69 9A B6 59 2C 05 A4 C7  | SW: E0 61 B3 8F 17 45 82 2B 7D F8 07 A0 A7 DC F8 65 3C 28 26
APDU: 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF FF FF FF F | APDU: 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF FF FF FF F
SW:                                                           | SW: 84 0E 76 69 4D 7C 35 F1 5F 1A DE D7 F3 2F 44 7E C5 8D 58



Comment 39 Ludovic Rousseau 2007-03-08 21:50:04 UTC
(In reply to comment #37)
> omnikey debug for comparison

The latest APDU of this trace is an extended APDU:
APDU: 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF ...
and it works:
SW: 84 0E 76 69 4D 7C 35 F1 5F 1A DE D7 F3 2F ...

So the Omnikey driver knows how to do extended APDU on a reader claiming normal APDU only. You can ask Omnikey to send me a patch for my CCID driver so it also support extended APDU on the Omnikey 6121.

You can either use the proprietary Omnikey driver (and not based on my driver) or use a reader with exteneded APDU support (any reader working on TPDU instead of APDU should be fine. Select one from http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/readers/?rev=0&sc=0).
Comment 40 Alon Bar-Lev (RETIRED) gentoo-dev 2007-03-09 05:42:44 UTC
Ludovic: Thanks for your help!
Comment 41 Radko Lazarov 2007-03-09 07:45:58 UTC
(In reply to comment #39)
> (In reply to comment #37)
> > omnikey debug for comparison
> The latest APDU of this trace is an extended APDU:
> APDU: 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF ...
> and it works:
> SW: 84 0E 76 69 4D 7C 35 F1 5F 1A DE D7 F3 2F ...
> So the Omnikey driver knows how to do extended APDU on a reader claiming normal
> APDU only. You can ask Omnikey to send me a patch for my CCID driver so it also
> support extended APDU on the Omnikey 6121.
> You can either use the proprietary Omnikey driver (and not based on my driver)
> or use a reader with exteneded APDU support (any reader working on TPDU instead
> of APDU should be fine. Select one from
> http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/readers/?rev=0&sc=0).


Thank you Ludovic. 

I'll ask OmniKey support for a patch or some usefull information how to do it.
I'm useing OmniKey driver at the moment, because I have no problems with it, but I definately prefer to work with OpenSource ccid driver. Also it would be better to have ccid driver supporting all features of this popular card reader.

I've check : http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/readers/?rev=0&sc=0

and I found OmniKey CardMan 6121 there, what does it mean??? I already have it and it is the problematic reader!
Comment 42 Ludovic Rousseau 2007-03-09 14:41:28 UTC
(In reply to comment #41)
> Also it would be
> better to have ccid driver supporting all features of this popular card reader.

It would be better if the reader correctly declare it is supporting extended APDU and support it the way it is defined by the CCID specification.

> I've check :
> http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/readers/?rev=0&sc=0
> 
> and I found OmniKey CardMan 6121 there, what does it mean??? I already have it
> and it is the problematic reader!

The reader is supported as a "Short APDU level exchange" reader.