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
Jun 10 22:32:03 oliver pcscd: ifdwrapper.c:520:IFDTransmit() Card not
Jun 10 22:32:03 oliver pcscd: winscard.c:1564:SCardTransmit() Card not
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 :
while using your libccid, I stumbled upon a problem with gpg2 when
trying to transmit a newly generated subkey to a GnuPG-card. The
- - 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
where the error occured if the command wasn't too long
00000008 APDU: 00 47 80 00 00 00 02 B6 00 08 00
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
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