I'll apply the patch. Thanks.

It seems that you missed the patch attached to the original submission, which
has all the required info: vendor ID is VENDOR_GEMPC (0x08e6), product ID is
0x3437, and the change to be applied indeed is in the internal CCID driver.

The reader is supported by PC/SC-lite, which never uses non-null NADs.

Could you please give more information, such as its USB vendor ID and product ID?
I assume that you are using GnuPG's internal CCID driver.
If you have a patch, please attach it here.
Is the reader supported by PC/SC-lite? If so, we could see how it is handled.

Right, it should work in 2.0.23.

@werner: I think, you mean 2.0.23

Should work in 2.0.13

On 2013-11-13 at 23:29 +0000, asdil12 via BTS wrote:

The fix for the login-data thing works fine.

The fix for the login-data thing works fine.

On 2013-11-12 at 21:29 +0000, asdil12 via BTS wrote:

asdil12 <dominik@heidler.eu> added the comment:

OK, I tested gnupg-2.0.22 with both patches applied, and it worked again.

I also noticed, that the pinpad won't be used - you would be asked via software

• (even if enable-pinpad-varlen was specified), if this

Login data .......: gpguser\n\x14P=6,8\n
thing was set on the card.

OK, I tested gnupg-2.0.22 with both patches applied, and it worked again.

I also noticed, that the pinpad won't be used - you would be asked via software

• (even if enable-pinpad-varlen was specified), if this

Login data .......: gpguser\n\x14P=6,8\n
thing was set on the card.

I tested on Archlinux (x86_64) applying my
patches on the current archlinux gnupg pkg.

On 2013-11-09 at 15:36 +0000, asdil12 via BTS wrote:

I just retried today using gnupg-2.0.22 with your patch, and it
failed again, if the enable-pinpad-varlen option was set:

the reiner reader also doesn't seem to work:

2013-11-09 17:00:48 scdaemon[7374] signatures created so far: 83
2013-11-09 17:00:48 scdaemon[7374] DBG: check_pcsc_pinpad: command=20, r=0
2013-11-09 17:00:48 scdaemon[7374] DBG: prompting for pinpad entry '||Please
enter the PIN%0A[sigs done: 83]'
2013-11-09 17:00:48 scdaemon[7374] DBG: send secure: c=00 i=20 p1=00 p2=81
len=24 pinmax=-1
2013-11-09 17:00:48 scdaemon[7374] DBG: response: sw=6B80 datalen=2
2013-11-09 17:00:48 scdaemon[7374] DBG: dismiss pinpad entry prompt
2013-11-09 17:00:48 scdaemon[7374] verify CHV1 failed: Card error
2013-11-09 17:00:48 scdaemon[7374] operation sign result: Card error
2013-11-09 17:00:48 scdaemon[7374] app_sign failed: Card error
2013-11-09 17:00:48 scdaemon[7374] updating slot 0 status: 0x0000->0x0007 (0->1)
2013-11-09 17:00:48 scdaemon[7374] sending signal 12 to client 4554

I just retried today using gnupg-2.0.22 with your patch, and it failed again, if
the enable-pinpad-varlen option was set:

one try:

2013-11-09 16:30:01 scdaemon[1536] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1
le=256 em=0
2013-11-09 16:30:01 scdaemon[1536] DBG: PCSC_data: 00 CA 00 C4 00
2013-11-09 16:30:01 scdaemon[1536] DBG: response: sw=9000 datalen=7
2013-11-09 16:30:01 scdaemon[1536] DBG: dump: 01 20 20 20 03 00 03
2013-11-09 16:30:01 scdaemon[1536] 3 Admin PIN attempts remaining before card is
permanently locked
2013-11-09 16:30:01 scdaemon[1536] DBG: check_pcsc_pinpad: command=20, r=0
2013-11-09 16:30:01 scdaemon[1536] DBG: prompting for pinpad entry '|A|Please
enter the Admin PIN'
2013-11-09 16:30:01 scdaemon[1536] DBG: send secure: c=00 i=20 p1=00 p2=83
len=24 pinmax=-1
2013-11-09 16:30:01 scdaemon[1536] pcsc_control failed: not transacted (0x80100016)
2013-11-09 16:30:01 scdaemon[1536] control_pcsc failed: 65547
2013-11-09 16:30:01 scdaemon[1536] DBG: dismiss pinpad entry prompt
2013-11-09 16:30:01 scdaemon[1536] verify CHV3 failed: General error

for the other try (with user pin), see attached log.

On 2013-10-16 at 06:16 +0000, asdil12 via BTS wrote:

You might use the known-
readers.txt from ccid
source, which lists usb-ids
and reader ames for
detection via pcscd. As
pcscd adds some text about
reader port to the string,
you can only match the
beginning of the string, but
that should do it.

You might use the known-
readers.txt from ccid
source, which lists usb-ids
and reader ames for
detection via pcscd. As
pcscd adds some text about
reader port to the string,
you can only match the
beginning of the string, but
that should do it.

On 2013-10-15 at 22:53 +0000, asdil12 via BTS wrote:

I applied your patch onto gnupg-2.0.22 source (I couldn't get the automake-foo
run through), and it worked again. (enable-pinpad-varlen set in config).
I used the cherry reader for testing.

I applied your patch onto gnupg-2.0.22 source (I couldn't get the automake-foo
run through), and it worked again. (enable-pinpad-varlen set in config).
I used the cherry reader for testing.

For auto detection of pinpad, it does the detection itself.

But the reader only works when we have some information on card [0] or
configuration of enable-pinpad-varlen.
That's because there is no good standard way to detect reader's capability
for variable length input.

Internal ccid driver has better support for variable length input detection
based on its USB ID.

It is currently, out of sync and it only works for SCM SPR 532.
I will add KAAN, FSIJ, REINER, VASCO, and CHERRY for PC/SC with USB ID, too.
I need users' help for PC/SC for detection with card reader name.

[0] http://wiki.gnupg.org/CardReader/GemaltoPC

Fixed in 2.0.x and master in git repository.
Please test it out.

BTW: shouldn't scd autodetect pinpad
support, or does this only work when using
internal ccid driver insted of pcsc?

Err... Sorry for your troubles. It's my fault.

my scdaemon.conf:
reader-port Cherry GmbH SmartTerminal ST-2xxx [Vendor Interface]
(21121310161160) 00 00
verbose
debug 2048
enable-pinpad-varlen
log-file /tmp/scd-pinpad.log

Can you please provide a debug log? Put the lines

verbose
debug 2048
log-file /foo/bar/scd.log

into ~/.gnupg/scdaemon.log - kill sdaemon and try again. Note that the PIN may
show up in the log.

Just tested with Cherry SMARTTERMINAL ST-2000U (via pcsc -> ccid).
Same issue with that reader, so not related to reiner-driver.

When I don't set the "enable-pinpad-varlen" option, pin-validation is done via
pc keyboard, if I do set the option, the complete action fails without asking
for the pin in any kind:

scdaemon[5137]: DBG: prompting for pinpad entry '||Please enter the PIN%0A[sigs
done: 46]'
scdaemon[5137]: DBG: dismiss pinpad entry prompt
scdaemon[5137]: verify CHV1 failed: Invalid value
scdaemon[5137]: app_sign failed: Invalid value
gpg: signing failed: Invalid value
gpg: signing failed: Invalid value

And pcscd must be restarted then, to get the setup working, again.

Meanwhile gniibe fixed a lot more bugs and also ported them back to 2.0. Thus I
close this bug.

No, I can't reproduce the problem. I just came to check the status of the bug.
Thanks for the info werner.

It was set to resolved in 2011 because I was not able to replicate it. Are you
now able to replicate the problem?

Hi!

Is this bug solved? And if yes, in what version is resolved?

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)

I just fixed a couple of card reader problems in GIT master. I assume that
theses fixes will also solve your problem.

D134: 305_used-scdaemon-doc.patch

We can't do anything about it.
Cards with manufacturer id 5 and serial numbers up to 346 (0x15a) are affected.
Newer cards work fine.

This is now a known problem. The likely reason is bug in the card's code. The
workaround is to forget about card based 3072 bit encryption keys.

Does the fact that I can encrypt, sign, and authenticate correctly with 3072 bit
keys affect your hypothesis?

According to http://pcsclite.alioth.debian.org/shouldwork.html#0x0B970x7762
this reader should work but it has not been tested.

Is there any more information I can provide? Can you reproduce it?

This is the built-in reader in my Dell Latitude D430, by the way.

This is the relevant lsusb output:

What card reader are you using?

This looks pretty much like a pc/sc problem. Please shutdown pcscd and use the
internal CCID driver. With PC/SC we don't have any control over the USB - we
don't even know what this is.

I checked this again and can't replicate this. The file is only written if the
status of the slot changed - independent of any client connection or the use of
SCD SERIALNO. If you lo updating slot 0 status: 0x0000->0x0007 (0->1)ok a the
logs (no options needed) you can clearly see that:

More info:

• scd killscd works when in the replug-without-hibernate case, for hibernate, a restart of pcscd is needed (probably not a scd problem).
• when I don't issue any commands to scd while the reader is unplugged, I can re-plug it anywhere (same or different usb port) and scd recognises this as a USABLE->ACTIVE->NOCARD->USABLE transition chain
• when I issue a SERIALNO command while the reader is unplugged, I get "Card Error" back (sitenote: shouldn't that be a ERR_NO_CARD_READER?) and that one sticks until a KILLSCD.
• this is not the case for other commands (tested: GETINFO version).

GPA works fine since it's full of sentinels blocking reentrance into the
reloading code, which I assume is triggered by the scdaemon behaviour
described. In addition, GPA causes the whole stack to wake up periodically to
reload data that didn't change. That's not nice for laptop users and
contributes to Global Warming :)

I see that this is a bit annoying. However I don't see the real problem. GPA
works just fine.

We should eventually do something about it. The problem is that you remove the
device and after plugging it in it is considered by the OS as a new device.
This also depends on the Os used and whether PC/SC, ctAPI or the internalCCID
driver is used.

The parser from libassun accepts lowercase variants. That is convenience
feature when working on the commandline with the assuan protocol. It should
never be used in any code. Attribute names are case-sensitive.

scd getinfo version

D 2.0.13-svn5059
$ ./src/gpa --version
gpa 0.9.0-svn996