When I try to do an "addcardkey" to a GnuPGv2 compliant smartcard and a
Cherry smartcard reader, the generation aborts with "card error".

The short output from the syslog is the following:

Jun 10 22:32:03 oliver pcscd: commands.c:1389:CCID_Receive Protocol
not supported
Jun 10 22:32:03 oliver pcscd: ifdwrapper.c:520:IFDTransmit() Card not
transacted
: 612
Jun 10 22:32:03 oliver pcscd: winscard.c:1564:SCardTransmit() Card not
transacte
d: 0x80100016

As I believed that there was something wrong with the pcsc-driver I'm
using (pcsclite), I mailed the maintainer Ludovic Rousseau who told me
to file a bug report here as there was some strange behavior within the
transmitted sequence (see mail text below). I'll also attach the exact
output of pcscd.

Le 10/06/12 15:21, Oliver Rümpelein a écrit :

Dear Ludovic,

Hello,

while using your libccid, I stumbled upon a problem with gpg2 when
trying to transmit a newly generated subkey to a GnuPG-card. The
important information:

• - driver version: 1.4.6
• - pcsc-lite-version: 1.8.3
• - smart card reader: Cherry ST-1044U (works fine with a friends Arch-Linux)
• - pcscd --version: see attachment
• - OS: Debian Wheezy (testing), currently running on Kernel 3.2.0
• - Middleware: libpcsclite1 / pcscd from standard-repository
• - Smart Card: GnuPG smartcard from kernelconcepts.de, provided by g10, running on BasicCard and developed by ZeitControl Log can be found in Attachement.

As said, the reader works like charm on a friends Arch-Linux laptop
with a similar GnuPG smartcard and the same drivers/middleware.

Do you do the same commands on your friends system? i.e. transmit the
newly generated subkey?

When I did a search for "CCID_receive Protocol not supported", the
only reference I found was this post
https://www.opensc-project.org/pipermail/opensc-user/2007-May/001782.html
where the error occured if the command wasn't too long

00000008 APDU: 00 47 80 00 00 00 02 B6 00 08 00
00000006 ifdhandler.c:1244:IFDHTransmitToICC()
usb:046a/002d:libudev:0:/dev/bus/usb/003/002 (lun: 0)
00000006 commands.c:1615:CmdXfrBlockTPDU_T0() T=0: 11 bytes
00000011 -> 000000 6F 0B 00 00 00 00 20 00 00 00 00 47 80 00 00 00 02 B6
00 08 00
00001732 <- 000000 80 00 00 00 00 00 20 40 F6 00
00000017 commands.c:1389:CCID_Receive Protocol not supported
00000006 SW:

The command "00 47 80 00 00 00 02 B6 00 08 00" sent to the reader is
strange.

CLA = 00 : OK

INS = 47 does not correspond to anything in ISO 7816-4. But it may be a
special command for the OpenPGP card.

P1 = 80 : PL

P2 = 00 : OK

Lc = 00 00 02 : extended APDU of size 2. Strange to use an extended APDU
for only 2 bytes.

Data = B6 00 : 2 bytes of data

Le = 08 : 8 bytes of expected answer

00 is an extra bye that should not be there.

I would say it is a bug in the gpg2 software. Check you are using the
latest version of gpg.
Report the bug (with my explanation) to the gpg2 maintainer.
http://www.gnupg.org/documentation/bts.en.html

Bye

--

Dr. Ludovic Rousseau