Sorry, Omnikey based readers are broken for keys >= ~ 2048 bit. See
http://pcsclite.alioth.debian.org/ccid_extended_apdu.html . The 4040 might not
be listed but it uses the same chip and doesn't work either.

However, I reverse engineered the protocol used by the Windows driver and
figured out how that driver does it. The SVN version has a hack which basically
works. I tested the 4040 and it works in most cases. The hack is not 100%
reliable but I was able to generate and use keys.

You need to use the internal CCID driver which requires that libusb headers are
installed at build time, pcscd is not running and you have sufficient
permissions to the USB port or well to the /dev/cmxN device (Linux) for the

4040. I don't know which device BSD uses for the 4040; if it is a different

one, check the transports list in scd/ccid-driver.c. I have no BSD running on a
laptop, thus I can't test it.

Werner Koch via BTS wrote:

However, I reverse engineered the protocol used by the Windows driver
and figured out how that driver does it. The SVN version has a hack
which basically works. I tested the 4040 and it works in most cases.
The hack is not 100% reliable but I was able to generate and use keys.

Thanks for your quick response. This sound really promising. On FreeBSD
the device will also be /dev/cmxN so that should be fine.

Unfortunately (just like yesterday, before your commit) the svn version
doesn't get very far on my machine. After starting a `gpg2 --card-edit'
it will block with an IPC error during the first card read. Every
command after that will just show the same error.

I've put up a log with debug info that might be of some use for you,
http://mud.stack.nl/~johans/v2-cmx.txt

Regards,
Johan

Are you sure that you are using the latest gpg-agent; i./e. that which comes
with the SVN version of GnuPG? The easiest way to use a nwer gpg-agent trhan
one that is already running is by using

gpg-agent --daemon /bin/sh

In that new shell everything shoutl be setup properly. Just make sure that no
other scdaemon is running (on behalf of anotrher gpg-agent).

If that all does not help, a log file from gpg-agent would be useful. Required
options gpg-agent.conf are the log-file and "debug 1024".

Werner Koch via BTS wrote:

Are you sure that you are using the latest gpg-agent;

I am very sure that I had replaced all the binaries before trying it,
but I didn't check if there was anything still running. Still, a new
check shows the same behaviour...

If that all does not help, a log file from gpg-agent would be useful.

Okay, I have put this logfile online at
http://mud.stack.nl/~johans/v2-cmx2.log

Johan

Werner Koch via BTS wrote:

If that all does not help, a log file from gpg-agent would be useful.
Required options gpg-agent.conf are the log-file and "debug 1024".

It seems that scdaemon crashed during the key generation procedure
(even during the log that I sent earlier). I've put a backtrace of the
scdaemon core dump online at http://mud.stack.nl/~johans/v2-cmx-core.txt

If I compile with debug info (-g -ggdb) then scdaemon will start eating
CPU and not terminate at all. I've attached gdb to this process as well
and put a backtrace up on http://mud.stack.nl/~johans/v2-cmx-hang.txt

Let me know if you need more information.

P.S. I'm running the svn version of gnupg, but release versions of
libraries that aren't in the gnupg directory.

Regards,
Johan

Are you still using the 4040?

#0 0x0000000800b3f44f in usb_control_msg ()

from /usr/local/lib/libusb-0.1.so.8

#1 0x000000000040f761 in abort_cmd (handle=0x8012aa040, seqno=90)

at ccid-driver.c:2033

indicates that you are using a real USB device. abort_cmd should terminate with
an error if used on a non-USB device.

<snip>

indicates that you are using a real USB device. abort_cmd should
terminate with an error if used on a non-USB device.

Yes, I'm pretty sure about that. The only USB device connected is
a mouse and there is no pcscd or similar tool running.

However I just did another svn update and it now seems to crash at a
different location. The agent logfile still looks the same as before,
http://mud.stack.nl/~johans/v2-cmx2.log

The new backtrace of the scdaemon core dump is available at
http://mud.stack.nl/~johans/v2-cmx-core2.txt

Regards,
Johan

Pth bug? Please try again after putting

debug-disable-ticker

into scdaemon.conf.

Werner Koch via BTS wrote:

Pth bug? Please try again after putting debug-disable-ticker
into scdaemon.conf.

Now scdaemon doesn't crash, but still aborts. An scdaemon logfile
is now online at http://mud.stack.nl/~johans/v2-cmx-scd.txt

Johan

I guess I should look at the freebsd driver. Any hint where to find it in the
freebsd svn?

Werner Koch via BTS wrote:

I guess I should look at the freebsd driver. Any hint where to find
it in the freebsd svn?

Yes, that would be /sys/dev/cmx/ - see online,
http://svn.freebsd.org/viewvc/base/head/sys/dev/cmx/
(or /usr/src/sys/dev/cmx/ on any install with sources).

Johan

What I noticed is that the driver uses a write timeout of (3*hz) for the CCID
ESCAPE command but (150*hz) for XFRBLOCK. My hack now uses the ESCAPE command
to send extended length APDU data blocks and they resemble what XFRBLOCK does.
My next test would be to change the timeout for the ESCAPE command in
cmx_timeout_by_cmd - I don't know whether this helps.

The Linux driver does exactly the same; I probably had luck when I tested the
key generation.

Enabling CMX_DEBUG should also give some insights.

We had some other reports on the ML about similar problems. Really time to go
after it.

Someone should check whether this has been fixed in the soon to be released 2.0.20.