Page MenuHome GnuPG

scd: reader pinpad stopped working with gnupg-2.0.22
Closed, ResolvedPublic

Description

This reader does not use the ccid-driver, but has an own pcsclite-driver (which
might not properly advertise pinpad features). Because of that, I specified
"enable-pinpad-varlen" in scdaemon.conf, which made the pinpad working. The
issue wasn't in gnupg-2.0.21, and I think, is's because of this patch:

+2013-08-30 NIIBE Yutaka <gniibe@fsij.org>
+
+ scd: PC/SC pinpad input improvement.
+ * scd/apdu.c (struct reader_table_s): Add members: PINMIN, PINMAX, and
+ PINPAD_VERLEN_SUPPORTED.
+ (CM_IOCTL_VENDOR_IFD_EXCHANGE, FEATURE_GET_TLV_PROPERTIES,
+ PCSCv2_PART10_PROPERTY_*): New.
+ (new_reader_slot): Initialize pinpad_varlen_supported, pinmin, pinmax.
+ (pcsc_vendor_specific_init): New.
+ (open_pcsc_reader_direct, open_pcsc_reader_wrapped): Call
+ pcsc_vendor_specific_init.
+ (check_pcsc_pinpad): Not detect here but use the result of
+ pcsc_vendor_specific_init.
+ (pcsc_pinpad_verify, pcsc_pinpad_modify): Specify bNumberMessage.
+

Details

Version
2.0.22

Event Timeline

asdil12 added projects: gnupg, Bug Report.
asdil12 added a subscriber: asdil12.
asdil12 renamed this task from scd: reiner-sct-rfid-standard reader pinpad stopped working with gnupg-2.0.22 to scd: reader pinpad stopped working with gnupg-2.0.22.Oct 8 2013, 10:48 PM
asdil12 raised the priority of this task from Normal to High.

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.

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.

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

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

On 2013-10-11 at 18:48 +0000, asdil12 via BTS wrote:

2013-10-11 20:46:34 scdaemon[2028] DBG: check_pcsc_pinpad: command=20,
r=0
2013-10-11 20:46:34 scdaemon[2028] DBG: prompting for pinpad entry '||
Please enter the PIN%0A[sigs done: 46]'
2013-10-11 20:46:34 scdaemon[2028] DBG: dismiss pinpad entry prompt
2013-10-11 20:46:34 scdaemon[2028] verify CHV1 failed: Invalid value
2013-10-11 20:46:34 scdaemon[2028] operation sign result: Invalid
value
2013-10-11 20:46:34 scdaemon[2028] app_sign failed: Invalid value

In 2.0.20, I introduced better handling of PINMIN, PINMAX for PC/SC
support. When possible, we now have information of supported PINMIN,
PINMAX of a card reader.

However, this "improvement" does bad thing. When a reader's PINMAX is
more than 25, the old check in the function pcsc_pinpad_modify bites
us.

/* Note that the 25 is the maximum value the SPR532 allows.  */
if (pininfo->minlen < 1 || pininfo->minlen > 25
    || pininfo->maxlen < 1 || pininfo->maxlen > 25
    || pininfo->minlen > pininfo->maxlen)
  return SW_HOST_INV_VALUE;

The log message "verify CHV1 failed: Invalid value" matches the
code of SW_HOST_INV_VALUE.

For Cherry SMARTTERMINAL ST-2000U, I think that GnuPG's internal ccid

driver (instead of PC/SC) should work well.

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

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

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

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.

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.

Thanks a lot for your testing.

I added information to scd/apdu.c so that users of known readers won't
need configuration of enable-pinpad-varlen.

The commit is:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=5efcc2b8fee8de31d255d09037f0a1e6209eab32

I also created a wiki page at:

http://wiki.gnupg.org/CardReader/PinpadInput

Thank you for your cooperation.

gniibe added a project: Restricted Project.

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

Thanks for your suggestion.

Basically, the string match for reader name is for Windows.

For GNU/Linux, pcscd works great and it supports GET_TLV_PROPERTIES.

We need the string match for system where GET_TLV_PROPERTIES won't

work.

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.

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

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:

Thanks for your testing.

I realized another bug, and pushed a fix to GnuPG repository today.

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=07d7015e4dcb8a2439ed781928495632ec0b4fa3;hp=04e5feea8b62e866520b2d24b6d2fa076bf

I believe this is related in your case.

Besides, please specify your tested environment (OS) in your report.

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

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.

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.

Thank you for testing. It helps me a lot.

I added another fix. Please test this again. I think that now it
also works with the case with login data.

I fixed the code so that GnuPG with PC/SC can work as same as

internal CCID driver.

The fix for the login-data thing works fine.

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

The fix for the login-data thing works fine.

Thanks a lot for your extensive tests.

werner removed a project: Restricted Project.

Should work in 2.0.13

asdil12 added a subscriber: wk.

@werner: I think, you mean 2.0.23

Right, it should work in 2.0.23.