Can't use pinpad with gnupg card #199
Comments
|
Leaving the PIN blank will not enable pinpad. pinpad is enable using OpenSC configuration file The application has to support Maybe your ssh application do not support |
|
I'm using OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013 with this special config: |
|
On 12/12/2013 8:46 AM, Dominik Heidler wrote:
To see what is going on with PKCS#11 can you try using pkcs11-spy: export PKCS11SPY_OUTPUT=/tmp/pkcs11spy.out then post to the mailing list the /tmp/pkcs11spy.out
Douglas E. Engert [email protected] |
|
|
It looks like a SSH bug/limitation. |
|
opensc still tried to do pinpad authentification: |
|
Also patching the |
|
On 12/12/2013 10:28 AM, Dominik Heidler wrote:
If you are still getting: Try running pcscd in debug mode to see the commands. something like: /usr/sbin/pcscd -a -f -d There were some issues with the byte order of the pin-pad commands. What is the endian of your processor? Does the pin-pad work for any other applications?
Douglas E. Engert [email protected] |
|
I'm working on a little endian system. I successfully used the pinpad with gnupg (latest git version, which has some fixes for variable pinlength) |
|
|
|
Sounds like the author(s) of the OpenSC openpgp support needs to look at the pin-pad code. On 12/12/2013 11:13 AM, Dominik Heidler wrote:
Douglas E. Engert [email protected] |
|
One more thing that might be helpful, is pcscd output of using the working openpgp code with the pin pad. Since the Cherry is a key board, could it be the openpgp code is not actually using the pin pad, On 12/12/2013 11:17 AM, Dominik Heidler wrote:
Douglas E. Engert [email protected] |
Your reader refused the pinpad command. The pinpad feature is poorly specified in the CCID specification. And many pinpad readers implement it in different ways. You czan try to change the different values. See http:https://anonscm.debian.org/viewvc/pcsclite/trunk/Drivers/ccid/examples/scardcontrol.c?view=markup (lines 538 and next) for an example. I do have this "Cherry GmbH SmartTerminal ST-2xxx" reader http:https://pcsclite.alioth.debian.org/ccid/supported.html#0x046A0x003E. But I don't know when I will have time to test OpenSC with it. |
|
Gnupg doesn't use ope sc, but uses pcscd via their scdaemon. Doug Engert [email protected] schrieb:
|
It isn't a keyboard - just a standalone reader with a pinpad.
|
|
OK - this is the pcscd log when using gnupg to sign a file and using the pinpad. |
|
This time the software is using: to be compared with: Maybe the problem is with bytes 6 and 7 corresponding to wPINMaxExtraDigit |
|
Yes - you're right - I tried this and was able to use the pinpad: diff --git a/src/libopensc/reader-pcsc.c b/src/libopensc/reader-pcsc.c
index 920b6f1..aae22fd 100644
--- a/src/libopensc/reader-pcsc.c
+++ b/src/libopensc/reader-pcsc.c
@@ -1564,6 +1564,9 @@ part10_find_property_by_tag(unsigned char buffer[], int length,
static int
part10_check_pin_min_max(sc_reader_t *reader, struct sc_pin_cmd_data *data)
{
+ data->pin1.min_length = 6;
+ data->pin1.max_length = 15;
+ return 0;
int r;
unsigned char buffer[256];
size_t length = sizeof buffer; |
|
This is how gnupg scdaemon seems to do that:
/* Check whether the reader supports the ISO command code COMMAND
on the pinpad. Return 0 on success. */
static int
check_pcsc_pinpad (int slot, int command, pininfo_t *pininfo)
{
int r;
if (reader_table[slot].pcsc.pinmin >= 0)
pininfo->minlen = reader_table[slot].pcsc.pinmin;
if (reader_table[slot].pcsc.pinmax >= 0)
pininfo->maxlen = reader_table[slot].pcsc.pinmax;
if (!pininfo->minlen)
pininfo->minlen = 1;
if (!pininfo->maxlen)
pininfo->maxlen = 15;
…
}
…
static int
pcsc_vendor_specific_init (int slot)
{
…
while (p < buf + len)
{
unsigned char tag = *p++;
int l = *p++;
unsigned int v = 0;
/* Umm... here is little endian, while the encoding above is big. */
if (l == 1)
v = p[0];
else if (l == 2)
v = ((p[1] << 8) | p[0]);
else if (l == 4)
v = ((p[3] << 24) | (p[2] << 16) | (p[1] << 8) | p[0]);
if (tag == PCSCv2_PART10_PROPERTY_bMinPINSize)
reader_table[slot].pcsc.pinmin = v;
else if (tag == PCSCv2_PART10_PROPERTY_bMaxPINSize)
reader_table[slot].pcsc.pinmax = v;
else if (tag == PCSCv2_PART10_PROPERTY_wIdVendor)
vendor = v;
else if (tag == PCSCv2_PART10_PROPERTY_wIdProduct)
product = v;
if (DBG_CARD_IO)
log_debug ("TLV properties: tag=%02X, len=%d, v=%08X\n", tag, l, v);
p += l;
}
…
} |
|
OpenSC has code to deal with PCSCv2_PART10_PROPERTY_bMaxPINSize in https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/reader-pcsc.c#L1595 But the CCID driver do not return the max pin size for the Cherry GmbH SmartTerminal ST-2xxx reader. So a default value has been used. I could not find where the max pin size of (default ?) 32 bytes comes from. |
|
I added some log - this is what |
|
I had a look at the gnupg-scdaemon code. So gnupg isn't getting that info from pcsc as well. |
|
When searching for the default pin length in opensc, I found another (possible) bug: In 3567660 there was a switch added, which is used in @@ -1408,6 +1408,9 @@ static int part10_build_modify_pin_block(struct sc_reader *reader, u8 * buf, siz
u8 tmp;
unsigned int tmp16;
PIN_MODIFY_STRUCTURE *pin_modify = (PIN_MODIFY_STRUCTURE *)buf;
+ struct sc_pin_cmd_pin *pin_ref =
+ data->flags & SC_PIN_CMD_IMPLICIT_CHANGE ?
+ &data->pin2 : &data->pin1;and @@ -1569,6 +1571,9 @@ part10_check_pin_min_max(sc_reader_t *reader, struct sc_pin_cmd_data *data)
unsigned char buffer[256];
size_t length = sizeof buffer;
struct pcsc_private_data *priv = GET_PRIV_DATA(reader);
+ struct sc_pin_cmd_pin *pin_ref =
+ data->flags & SC_PIN_CMD_IMPLICIT_CHANGE ?
+ &data->pin1 : &data->pin2;Note that the order (pin1:pin2 vs pin2:pin1) is different. I think, pin2:pin1 is correct. |
|
where does the default 6-32 for pin1 comes from? 32 is a huge value. |
|
The 6-32 values are already present in the |
|
Is's also already present in rv = slot_get_token(slotID, &slot); |
|
I think, I found the source: It's the card itself: I also tried a Feitian card (p15dump reports 4-16) and my debug prints also returned 4-16 for the default pin min/max. |
|
So your card may have a pin code of 32 digits. But it will then be impossible to enter it using the Cherry GmbH SmartTerminal ST-2xxx. Maybe OpenSC should limit the maximal pin length if the driver returns a value with Can you do some tests with your reader and tell me the minimum and maximum PIN lengths supported by the SmartTerminal ST-2xxx (so I can add them in the CCID driver)? |
|
I can't test this at home, because my home pc (arch) seems to run into different issues than my pc at work (suse). But I think, that 4-15 would be a good start. The issue on my home pc seems to be a too small request block: I even tried the opensc binaries from my pc at work on my home pc - with the same result. |
|
Your request block is wrong. You indicates an APDU of 5 bytes but give only 4. I would like to use the real values for PIN size min/max, and not just a good start. |
|
OK - just did some testing: the reader accepts a min_length of 1 and a max_length of 25. |
|
The "Wrong lengths: 24 23" problem was a bug on my side in ccid/examples/scardcontrol.c. Sorry for that. I fixed it in revision 6809 http:https://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2013-December/006364.html |
|
based on 48ec5b1 the same changes as in scardcontrol.c have to be done in reader-pcsc.c Line numbers may be off due to unrelated changes in PACE code and hardcoded maximum PIN length. diff --git a/src/libopensc/reader-pcsc.c b/src/libopensc/reader-pcsc.c
--- a/src/libopensc/reader-pcsc.c
+++ b/src/libopensc/reader-pcsc.c
@@ -1396,7 +1400,7 @@ static int part10_build_verify_pin_block(struct sc_reader *reader, u8 * buf, siz
pin_verify->ulDataLength = HOST_TO_CCID_32(offset); /* APDU size */
- count = sizeof(PIN_VERIFY_STRUCTURE) + offset -1;
+ count = sizeof(PIN_VERIFY_STRUCTURE) + offset;
*size = count;
return SC_SUCCESS;
}
@@ -1515,7 +1519,7 @@ static int part10_build_modify_pin_block(struct sc_reader *reader, u8 * buf, siz
pin_modify->ulDataLength = HOST_TO_CCID_32(offset); /* APDU size */
- count = sizeof(PIN_MODIFY_STRUCTURE) + offset -1;
+ count = sizeof(PIN_MODIFY_STRUCTURE) + offset;
*size = count;
return SC_SUCCESS;
}This change fixed it |
|
The CCID driver now reports the min/max PIN sizes for the SmartTerminal ST-2xxx reader |
The PC/SC v2 part 10 commands for PIN verify and modify were wrong after a change in pcsc-lite. See a similar change in http:https://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2013-December/006364.html Should fix issue #199
|
Does opensc already respect the pin min/max size reported by ccid? |
|
OpenSC is using |
The Cherry GmbH SmartTerminal ST-2xxx reader has a min PIN size of 0 digits and a max PIN size of 25 (0x19) digits. Thanks to Dominik Heidler for the bug report OpenSC/OpenSC#199 git-svn-id: svn:https://anonscm.debian.org/pcsclite/trunk/Drivers/ccid@6811 0ce88b0d-b2fd-0310-8134-9614164e65ea
I'm using the GPGv2 card for SSH. Entering the PIN through the terminal works fine, but if I leave the PIN blank and press ok (which triggers pinpad input as far as I know), the PIN isn't requested via pinpad.
My Reader: Cherry GmbH SmartTerminal ST-2xxx
I'm using opensc 0.13
Log:
The text was updated successfully, but these errors were encountered: