Page MenuHome GnuPG

Print a warning for readers not supporting extended APDUs.
Open, NormalPublic


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
: 612
Jun 10 22:32:03 oliver pcscd: winscard.c:1564:SCardTransmit() Card not
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,


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, 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
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

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.



Dr. Ludovic Rousseau



Event Timeline

pheerai set Version to 2.0.19.
pheerai added a subscriber: pheerai.

The CMD 0x47 is an ISO7816-8 command (Generate keypair). I suggest to enable
debugging in scdaemon: Put this into ~/.gnupg/scdaemon.conf

log-file /foo/bar/mylog
debug 1024
debug 2048

kill scdaemon and try again. It is possible that the reader fails due to the
genrate key command. Another option is a problem in pcscd. Stop pcscd, make
sure you have write permissions to the reader's device under /dev/bus/usb, and
tru again. This will use scdaemons internal driver.

The debug-output of scdaemon can be found here:

And I do have write permission on the device.

werner lowered the priority of this task from High to Normal.Jun 20 2012, 10:24 AM

That is the same error as in your first report. It is either a
problem of the reader or of pcscd. Please stop pcscd and try with the
internal driver.

Ludovic: Using an extend APDU with a 3 byte Lc is not strange - even
if the value of Lc is only 2. This is Case 4E in 7816-4.

We need to use an extended APDU because we need to specify the
expected return length Le as larger than 256. We use 2048 here
(0x0800) because that is the maximum length of response data for this
specific card. Although we don't expect a 2048 byte response, we
expect one that is larger than 256 and thus we need to request an
Extended Length APDU. The 2048 is required for other commands and
thus the reader need to support it anyway.

Ludovic noticed that this reader does not support extended APDUs (Log says
"Short APDU level exchange"). Thus there is no way to use this reader for 2k keys.

He also suggested to print a warning for such readers. That is a good idea.

werner renamed this task from CCID-Receive Protocol not supported to Print a warning for readers not supporting extended APDUs..Jun 20 2012, 4:05 PM
werner added a project: scd.
werner removed a project: Bug Report.
werner added a project: Feature Request.
werner added a project: gnupg.

I will stay prepared for any testing or debugging that might be requested by
anyone of you guys (but it might take a week, as the reader belongs to someone
else), such a warning could have saved lots of time for each one of us.

And, only for your files, I made a mistake in the first E-Mail I wrote Ludovic:
It's not a Cherry ST-1044U, but a Cherry XX44 smartcard reader (ST-1044U seems
to be the USB-Descriptor)