gpg4win pinentry ignores pinpad

NIIBE Yutaka gniibe at
Thu Oct 24 04:01:24 CEST 2013

On 2013-10-23 at 13:50 +0200, Martin Wolters wrote:
> I use a SPR332, which should be supported by gpg4win 2.2.1, but the
> pinpad is not used. check_pcsc_pinpad() returns SW_NOT_SUPPORTED and
> pinentry then prompts me to enter the PIN with my keyboard.

I can't answer to your build problem (I don't have knowledge).  I only
answer to your pinpad problem.

I don't know if we have any experience with SPR332.  By the way, this
month, I created a Wiki page for pinpad input, so that it helps users:

In that page, I am gathering information about readers which support
pinpad input.

Well, let me explain scdaemon.  The scdaemon works like this:

  (1) When opening the connection (open_pcsc_reader), it calls
      pcsc_vendor_specific_init to get vendor specific information,
      specifically, information for pinpad input.

  (1-1) It calls conrol_pcsc with CM_IOCTL_GET_FEATURE_REQUEST.
        Here, reader_table[slot].pcsc.verify_ioctl (and others) is
        filled, if the reader supports FEATURE_VERIFY_PIN_DIRECT.

  (1-2) It calls conrol_pcsc with GET_TLV_PROPERTIES.

  (2) When apdu_check_pinpad is called, it calls check_pcsc_pinpad
      to check if the reader support pinpad input.
      When reader_table[slot].pcsc.verify_ioctl is filled it returns
      0 (success).

It seems for me that you've tried to circumvent the checking of (2),
but the real issue is (1-1).

> scdaemon[15820]: chan_00000138 -> OK GNU Privacy Guard's Smartcard
> server ready
> scdaemon[15820]: chan_00000138 <- GETINFO socket_name
> scdaemon[15820]: chan_00000138 -> D
> C:UsersasdfAppDataRoaminggnupgS.scdaemon
> scdaemon[15820]: chan_00000138 -> OK
> scdaemon[15820]: chan_00000138 <- OPTION event-signal=f8
> scdaemon[15820]: chan_00000138 -> OK
> scdaemon[15820]: chan_00000138 <- SERIALNO openpgp

Here, we don't see any log (for the step (1-1)).

If it fails for CM_IOCTL_GET_FEATURE_REQUEST, we might see something

   pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: ...

Or else, we should see:

   feature: code=??, len=??, v=??

We don't see any log...  It means that the call got success, but it
returned empty information.  In this situation, pinpad input doesn't

> 2013-10-22 19:53:08 scdaemon[15820] DBG: check_pcsc_pinpad: command=20,
> r=27265

This is at (2).

Well, I found an article in OpenSC mailng list:

Could you check your firmware version?

More information about the Gnupg-devel mailing list