Page MenuHome GnuPG

Gemalto Ezio Shield (CT710): CCID command failed: Parameter error at offset 7
Closed, ResolvedPublic

Description

Operating system: Ubuntu 18.04.2 LTS
Smart card: OpenPGP Smart Card V2.1

I have two different smartcard readers:

Both readers work fine when pcscd is installed. But when I remove pcscd, only the Cherry ST-2000 reader will work. With the Gemalto Ezio Shield, gpg --card-status all won't print anything, and the following error is reported in scdaemon's debug output:

2019-07-24 17:53:05 scdaemon[31116] reader slot 0: using ccid driver
2019-07-24 17:53:05 scdaemon[31116] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
2019-07-24 17:53:05 scdaemon[31116] DBG: enter: apdu_connect: slot=0
2019-07-24 17:53:05 scdaemon[31116] DBG: leave: apdu_connect => sw=0x0
2019-07-24 17:53:05 scdaemon[31116] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0
2019-07-24 17:53:05 scdaemon[31116] DBG:  raw apdu: 00 A4 00 0C 02 3F 00
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   dwLength ..........: 7
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bSlot .............: 0
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bSeq ..............: 4
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   [0010]  00 A4 00 0C 02 3F
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   [0016]  00
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   dwLength ..........: 0
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bSlot .............: 0
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bSeq ..............: 4
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bStatus ...........: 64
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bError ............: 7
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver: CCID command failed: Parameter error at offset 7
2019-07-24 17:53:05 scdaemon[31116] apdu_send_simple(0) failed: unknown status error
2019-07-24 17:53:05 scdaemon[31116] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0
2019-07-24 17:53:05 scdaemon[31116] DBG:  raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   dwLength ..........: 11
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bSlot .............: 0
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bSeq ..............: 5
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   [0010]  00 A4 04 00 06 D2
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   [0016]  76 00 01 24 01
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   dwLength ..........: 0
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bSlot .............: 0
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bSeq ..............: 5
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bStatus ...........: 64
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver:   bError ............: 7
2019-07-24 17:53:05 scdaemon[31116] DBG: ccid-driver: CCID command failed: Parameter error at offset 7
2019-07-24 17:53:05 scdaemon[31116] apdu_send_simple(0) failed: unknown status error
2019-07-24 17:53:05 scdaemon[31116] can't select application 'openpgp': Nicht unterstützt
2019-07-24 17:53:05 scdaemon[31116] DBG: enter: apdu_close_reader: slot=0
2019-07-24 17:53:05 scdaemon[31116] DBG: enter: apdu_disconnect: slot=0
2019-07-24 17:53:05 scdaemon[31116] DBG: leave: apdu_disconnect => sw=0x0

I've enabled debugging in my scdaemon.conf with the following configuration:

verbose
debug-level guru
debug-ccid-driver
log-file /home/martin/scdaemon.log

The full scdaemon.log is attached below.

The reasons why I want to remove pcscd are:

  • Some colleagues are using MacOS, where pcscd is not available; this problem seems to affects them too - the Cherry reader works fine, the Gemalto reader doesn't work at all.
  • We are considering to use multiple smartcards at the same time for OpenSSH MFA (e.g. a user needs to have two smartcards inserted at the same time to connect to a server). As far as I know, using multiple smartcard readers and smartcards at the same time is only supported by scdaemon's internal CCID driver, and doesn't work with pcscd. At least I was only able to get it working with two Cherry readers and the internal CCID driver, and not with pcscd installed.

I suspect that the Gemalto reader is probably doing something stupid (I've seen workarounds both in [[ https://salsa.debian.org/rousseau/CCID/blob/master/src/ccid.c#L461 | libccid's code ]] and in [[ https://dev.gnupg.org/source/gnupg/browse/master/scd/ccid-driver.c;044379772fc5b0f39c6a36809722e702808b6ec3$1239 | scdaemon's code ]] for an issue where the readers send a VERIFY command with an empty PIN to the card, which the OpenPGP smart card apparently doesn't support).

I've tried to fiddle with the code to see if a similar workaround might fix the issue for my Gemalto reader, but I'm afraid this hasn't led anywhere. I understand that this probably isn't easy to fix without access to this specific smart card reader, but if anyone has any suggestions what I could try out, they would be appreciated :)

Details

Version
2.2.4

Revisions and Commits

Event Timeline

gniibe added a subscriber: gniibe.

Thanks for your report, with helpful log.

In the internal CCID driver, currently, it uses bBWI=4 (Block Waiting Index, the parameter at offset 7), hard-coded, for some reason.

I think that it is due to the situation around 2003 when libusb was not mature, old reader(s) and old smartcard implementation(s) were not good; I think that the intention is let the reader be patient enough.

We can change it to bBWI=0 as default (only use specific bwi value for wait time extension request).
That's the standard way, as libccid (of PC/SC lite) does.

Let me try.

Wow, thanks for the quick response! I've applied your patch to the Ubuntu package (2.2.4-1ubuntu1.2), and gpg --card-status now works fine:

martin@dogmeat ~ % gpg --card-status all

Reader ...........: 08E6:34C2:S14C0138574843:0
Application ID ...: D276000124010201000500004D660000
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 00004D66
Name of cardholder: [nicht gesetzt]
Language prefs ...: de
Sex ..............: unbestimmt
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 10
Signature key ....: 8197 4D2F CDC6 540F FAEE  6E42 FD29 791E 19AB 6E5B
      created ....: 2019-07-19 12:39:38
Encryption key....: 6425 4278 3C77 9DD9 EDA2  D2E7 1B4F 3F59 B99C 513B
      created ....: 2019-07-19 12:39:38
Authentication key: 6316 DCA2 2371 529F B30C  5669 F2EF EBBE 4D51 B4AC
      created ....: 2019-07-19 12:39:38
General key info..: pub  rsa2048/FD29791E19AB6E5B 2019-07-19 Karte 4D66 <4d66@iserv.eu>
sec>  rsa2048/FD29791E19AB6E5B  erzeugt: 2019-07-19  verfällt: 2023-07-18
                                Kartennummer: 0005 00004D66
ssb>  rsa2048/F2EFEBBE4D51B4AC  erzeugt: 2019-07-19  verfällt: 2023-07-18
                                Kartennummer: 0005 00004D66
ssb>  rsa2048/1B4F3F59B99C513B  erzeugt: 2019-07-19  verfällt: 2023-07-18
                                Kartennummer: 0005 00004D66

Unfortunately, secure PIN entry doesn't work - it'll prompt for the PIN on the PC. I've attached a new scdaemon.log (I realize that this contains my PIN, but it's only a test card with PIN 123456 anyway ^^).

I have to admit though that currently I can't even get secure PIN entry working even with pcscd installed. IIRC this worked once, not sure what I'm doing wrong?

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

Beside, Gemalto Ezio Shield only supports short APDU, which doesn't work well with >= 2048 RSA key.
Signing/Authentication is OK, but encryption doesn't work.

See T1405: Print a warning for readers not supporting extended APDUs..

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

Oooh, that was the thing I've been missing. I had the option enable-pinpad-varlen set in my scdaemon.conf, but I couldn't remember why and so I removed it before creating the debug log in my original report. I just re-enabled it, and now secure PIN entry works (at least with PIN 123456). I've seen in the code that you hardcode the supported maxlen, so I also tested longer PINs - up to 40 characters seem to work fine (tested with PIN 40x "1"). I don't think I can determine if minlen is <6, as I only have OpenPGP cards and those have a minlen of 6. Anything more I should test?

Beside, Gemalto Ezio Shield only supports short APDU, which doesn't work well with >= 2048 RSA key.

Hmm, I think it may. It's a bit confusing because apparently there are multiple different readers called "Gemalto Ezio Shield":

https://ccid.apdu.fr/ccid/supported.html#0x08E60x34C0
https://ccid.apdu.fr/ccid/shouldwork.html#0x08E60x34C2

0x34C0 doesn't support extended APDUs, but for 0x34C2, libccid doesn't list that limitation. I have 0x34C2, so I think extended APDUs should work...? I ran ccid-1.4.30/src/parse, and it reports:

dwFeatures: 0x000404B2
 ....02 Automatic parameter configuration based on ATR data
 ....10 Automatic ICC clock frequency change according to parameters
 ....20 Automatic baud rate change according to frequency and Fi, Di params
 ....80 Automatic PPS made by the CCID
 ..04.. Automatic IFSD exchange as first exchange (T=1)
 04.... Short and Extended APDU level exchange

Thanks. So, this is a positive report for 8E60:34C2. I'm going to add this VID:PID to support pinpad input by the internal CCID driver.

Not sure what I did wrong this time, but it's broken again - GPG will again prompt for the PIN on my computer instead of on the Gemalto Ezio Shield reader :(

I'm using GnuPG 2.2.4-1ubuntu1.2 with your patch applied:

martin@dogmeat patches % pwd
/home/martin/src/gnupg2-2.2.4/debian/patches
martin@dogmeat patches % cat martin-fix-T4654.patch 
Description: <short summary of the patch>
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 gnupg2 (2.2.4-1ubuntu1.2) bionic-security; urgency=medium
 .
   * SECURITY UPDATE: CSRF in dirmngr
     - debian/patches/CVE-2018-1000858.patch: don't follow a redirect in
       dirmngr/Makefile.am, dirmngr/http.c, dirmngr/http.h,
       dirmngr/ks-engine-hkp.c, dirmngr/ks-engine-http.c,
       dirmngr/t-http-basic.c, dirmngr/t-http.c.
     - CVE-2018-1000858
Author: Marc Deslauriers <marc.deslauriers@ubuntu.com>

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: <vendor|upstream|other>, <url of original patch>
Bug: <url in upstream bugtracker>
Bug-Debian: https://bugs.debian.org/<bugnumber>
Bug-Ubuntu: https://launchpad.net/bugs/<bugnumber>
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By: <name and email of someone who approved the patch>
Last-Update: 2019-10-08

--- gnupg2-2.2.4.orig/scd/ccid-driver.c
+++ gnupg2-2.2.4/scd/ccid-driver.c
@@ -2816,7 +2816,7 @@ ccid_transceive_apdu_level (ccid_driver_
   size_t apdu_part_len;
   size_t msglen;
   unsigned char seqno;
-  int bwi = 4;
+  int bwi = 0;
   unsigned char chain = 0;
 
   if (apdu_len == 0 || apdu_len > sizeof (msg) - 10)
@@ -3068,7 +3068,7 @@ ccid_transceive (ccid_driver_t handle,
           msg[0] = PC_to_RDR_XfrBlock;
           msg[5] = 0; /* slot */
           msg[6] = seqno = handle->seqno++;
-          msg[7] = 4; /* bBWI */
+          msg[7] = wait_more; /* bBWI */
           msg[8] = 0; /* RFU */
           msg[9] = 0; /* RFU */
           set_msg_len (msg, tpdulen);

My scdaemon.conf:

martin@dogmeat ~ % cat .gnupg/scdaemon.conf
verbose
debug-level guru
debug-ccid-driver
log-file /home/martin/scdaemon.log
enable-pinpad-varlen

pcscd is not installed, so it should be using the internal driver. pinpadtest.py works fine (but only with pcscd installed).

scdaemon.log:

Dear Martin,

Gemalto Ezio Shield is a tricky piece of middleware connector. In Portugal, we take "Public Money, Public Code" seriously and I find that this production code maybe comes handy while we try to sort out this specific problem, unfortunately, I am a layman regards to systems interoperability.

https://svn.gov.pt/projects/ccidadao/browser/middleware-offline/trunk/_src/eidmw/cardlayer/GempcPinpad.cpp

All The best,

@pow, thanks for a reference. But problem here is that there are multiple products with same name.

@martin.von.wittich , sorry, I forgot to push my change for adding 0x08e6:34c2.

I just pushed rGc933c15d587a: scd,ccid: Add 08e6:34c2 (GEMPC_EZIO)..

Please test. When I can confirm that it is stable, I'll backport it to 2.2.

@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC

Please test. When I can confirm that it is stable, I'll backport it to 2.2.

Hmm, almost, but not quite. It worked fine during my first attempt, but then I noticed that I still had the debug options including enable-pinpad-varlen in my scdaemon.conf, so I commented everything in scdaemon.log. On all subsequent attempts, GPG would prompt for the PIN on my computer. I noticed in your patch that you set enable_varlen = 0 for GEMPC_EZIO - why is that? When I change that to 1 and recompile, it works as expected, prompting me for my PIN on the reader.

Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.

This will be in 2.2.18, closing.