Thank you for your registering an issue at BTS.

In fact, we had a similar report last month:

https://lists.gnupg.org/pipermail/gnupg-users/2015-June/053708.html

On 06/08/2015 11:48 PM, asdil12 via BTS wrote:

I'm using the Cherry GmbH SmartTerminal ST-2xxx reader and cannot use the card
without specifying disable-pinpad in scdaemon.conf:

gpg: public key decryption failed: Invalid value
gpg: decryption failed: No secret key

When I disable the pinpad using the option from above, everything works fine.

Could you try with GnuPG's instock CCID driver (instead of PC/SC driver),
(if your system is not Windows)?

Please stop PC/SC service and setup access permission to the device, then,
run gpgp. Configuration is something like:

• .gnupg/scdaemon.conf

debug-level guru
debug-all
log-file /tmp/scd.log

debug-ccid-driver

--

When you are using PC/SC service and Python and pyscard works
well on your system, please try my pinpadtest.py script.

pyscard: http://pyscard.sourceforge.net/

pinpadtest.py:

http://git.gniibe.org/gitweb/?p=gnuk/gnuk.git;a=blob;f=tool/pinpadtest.py

$ ./pinpadtest.py
Reader/Token: Cherry GmbH SmartTerminal ST-2xxx [Vendor Interface] (000004fa) 00 00
ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
Please input User's PIN
Traceback (most recent call last):

File "./pinpadtest.py", line 378, in <module>
  main(who, method, add_a_byte, pinmin, pinmax, change_by_two_steps, fixed)
File "./pinpadtest.py", line 242, in main
  card.cmd_verify_pinpad(who)
File "./pinpadtest.py", line 138, in cmd_verify_pinpad
  raise ValueError, ("cmd_verify_pinpad %02x %02x" % (sw1, sw2))

ValueError: cmd_verify_pinpad 69 82

Same error when using gnupg's CCID.

Thank you for testing.

Does it means it works for you?

$ ./pinpadtest.py
Reader/Token: Cherry GmbH SmartTerminal ST-2xxx [Vendor Interface] (000004fa) 00 00
ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
Please input User's PIN
Traceback (most recent call last):

File "./pinpadtest.py", line 378, in <module>
  main(who, method, add_a_byte, pinmin, pinmax, change_by_two_steps, fixed)
File "./pinpadtest.py", line 242, in main
  card.cmd_verify_pinpad(who)
File "./pinpadtest.py", line 138, in cmd_verify_pinpad
  raise ValueError, ("cmd_verify_pinpad %02x %02x" % (sw1, sw2))

ValueError: cmd_verify_pinpad 69 82

6982 means PIN is wrong ("Security Failure").

It seems that the card reader prompted you PIN. Did you input
by the pinpad?

If so, I guess that it is the value of PINMIN and PINMAX in the
implementation of GnuPG SCDaemon, which should be fixed.

I guess that following won't work.

$ ./pinpadtest.py --pinmin 0 --pinmax 25

Currently, for PC/SC, we have a function pcsc_vendor_specific_init in
gnupg/scd/apdu.c to check the value of PINMIN and PINMAX.

In your scd.log, we had following lines:

2015-06-08 16:43:29 scdaemon[2889] DBG: TLV properties: tag=06, len=1, v=00000000

2015-06-08 16:43:29 scdaemon[2889] DBG: TLV properties: tag=07, len=1, v=00000019

It means that PC/SC service informed SCDaemon, saying, the reader's
PINMIN and PINMAX is 0 and 25, respectively. Then, SCDaemon used

those values.

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

Same error when using gnupg's CCID.

Thanks a lot for testing. It gives me much information.

Did your card reader prompt PIN and you enter the PIN?

The error was:

2015-06-11 15:47:01 scdaemon[29262] DBG: ccid-driver: RDR_to_PC_DataBlock:
2015-06-11 15:47:01 scdaemon[29262] DBG: ccid-driver: dwLength ..........: 6
2015-06-11 15:47:01 scdaemon[29262] DBG: ccid-driver: bSlot .............: 0
2015-06-11 15:47:01 scdaemon[29262] DBG: ccid-driver: bSeq ..............: 55
2015-06-11 15:47:01 scdaemon[29262] DBG: ccid-driver: bStatus ...........: 0

2015-06-11 15:47:01 scdaemon[29262] DBG: ccid-driver: [0010] 00 40 02 67 00 25

The packet is:

	  Prologue   Information   Epilogue

nad len
00 40 02 67 00 25

	    PCB

So, it returned APDU of 6700, which means "WRONG LENGTH".

I don't know the reason why it returns "WRONG LENGTH", but
possibly, your reader doesn't support variable length PIN.

With PC/SC service, does following work for you?

$ ./pinpadtest.py --pinmin 6 --pinmax 6 --fixed 6

--

I'm pretty sure that the reader supports varlength pinpad input - it is the same
device that was used here: T1549

Let's confirm facts.
(1) pinpadtest.py with no option works? Prompt on the reader? And you can input PIN?
(2) Or else, pinpadtest.py --add works?
(3) When (1) and (2) fail, pinpadtest.py --pinmin 6 --pinmax 15 works?
(4) When (1), (2), and (3) fail, pinpadtest.py --pinmin 6 --pinmax 15 --add works?

(1) pinpadtest.py with no option works? Prompt on the reader? And you can input PIN?

The padlock LED on the reader blinks and I enter the pin. When I press
the green return button on the reader, the traceback is shown.
Also the PIN retry counter is decremented (which was quite a cavecat for
debugging)

(2) Or else, pinpadtest.py --add works?

$ ./pinpadtest.py --add
Reader/Token: Cherry GmbH SmartTerminal ST-2xxx [Vendor Interface]
(000004fa) 00 00
ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
Please input User's PIN
OK.

D309: 638_scd-add-zero.diff

Thank you for your testing.
For in-stock CCID driver, could you please test this patch?
For PC/SC, I'm going to investigate the issue.

Also an interesting fact: the pin retry counter is only decremented,
when using your python script for testing - not when using gnupg.

When using gnupg without gpg and with your patch applied, pinpad works.

I think that:
(1) When all correct, it works well (patched case)
(2) When it's mostly correct but problem with length, it doesn't work (no prompt
to user) and retry counter is decremented. (pinpadtest script case)
(3) When it's bad, it doesn't work and retry counter keeps its value (current gpg)

Here is current patch. This includes change for PC/SC.

D308: 646_scd-change-st-2000-20150619.diff

For the pinpadtest script case (without the --add parameter) it actually asks
for the pin, but when I press enter to confirm, the retry counter is decremented
and the stacktrace is shown.

On 06/19/2015 04:13 PM, asdil12 via BTS wrote:

For the pinpadtest script case (without the --add parameter) it actually asks
for the pin, but when I press enter to confirm, the retry counter is decremented
and the stacktrace is shown.

Thanks a lot for your clarification.

The process is like this:

Host sends a template of APDU to the card reader.
Card reader asks a user to input PIN.
Card reader composes APDU by the template and sends it to card.

So, it means that card reader's composing of APDU with the template
goes wrong; while it is recognized as valid APDU by card, but it is

recognized as wrong PIN.

scd-change-st-2000-20150619.diff doesn't seem to fix PC/SC - it only
works when PC/SC daemon is not running (and therefor gnupg's internal
CCID driver is used).

For PC/SC, it is confirmed with GemPCPinpad SmartCard Reader on Debian GNU/Linux.
Fix is applied to the development repo.
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=5e1d2fe6555d06f9dcd2daac713b2edfbc0428a5

I believe that this fix finally resolves the issue.

The fixes are included into 2.1.6.
Please test GnuPG 2.1.6.

works fine with gnupg 2.1.6 and pc/sc.