Wring PKCS#11 signatures when using pcsc.

Hi all,

 I just discovered a problem, with m reiner PINpad reader:

When I use opensc (current SVN) together with
ctapi-cyberjack, I'm able to 
generate RSA/SHA1 signatures with no problem using opensc's

pkcs11-implementation.

When I access the same chipcard reader or any other read (In
my case gempc 
card/PCMCIA) via pcsc-lite, the computed signatures are
wrong an connot be 
verified against the matching public key.

As a side-effect, opensc does not recognize the pinpad, when
using the pinpad 
reader with pcsc, so I have to enter the PIN on the command
line.

  Did anybody have the same problem ?


   Wolfgang
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

Wolfgang Glas wrote:
> Hi all,
> 
>  I just discovered a problem, with m reiner PINpad
reader:
> 
> When I use opensc (current SVN) together with
ctapi-cyberjack, I'm able to 
> generate RSA/SHA1 signatures with no problem using
opensc's 
> pkcs11-implementation.
> 
> When I access the same chipcard reader or any other
read (In my case gempc 
> card/PCMCIA) via pcsc-lite, the computed signatures are
wrong an connot be 
> verified against the matching public key.
> 
> As a side-effect, opensc does not recognize the pinpad,
when using the pinpad 
> reader with pcsc, so I have to enter the PIN on the
command line.

what kind of signatures (i.e. 2048 bit ?) ?
Does the debug log show something interesting ?

Cheers,
Nils
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

Am Mittwoch, 2. August 2006 18:23 schrieb Nils Larsch:
> Wolfgang Glas wrote:
> > Hi all,
> >
> >  I just discovered a problem, with m reiner PINpad
reader:
> >
> > When I use opensc (current SVN) together with
ctapi-cyberjack, I'm able
> > to generate RSA/SHA1 signatures with no problem
using opensc's
> > pkcs11-implementation.
> >
> > When I access the same chipcard reader or any
other read (In my case
> > gempc card/PCMCIA) via pcsc-lite, the computed
signatures are wrong an
> > connot be verified against the matching public
key.
> >
> > As a side-effect, opensc does not recognize the
pinpad, when using the
> > pinpad reader with pcsc, so I have to enter the
PIN on the command line.
>
> what kind of signatures (i.e. 2048 bit ?) ?
> Does the debug log show something interesting ?

OK, I've checked the logs and it boiled down to a problem,
that a 2048 bit 
signature for cardos 4.3b is a 265 byte APDU to be
transmitted to the card.

The maximal buffer in pcsc-lite has been configured to 264
and the maximal 
buffer in the accompanying ccid driver has been set to
263(!). The attached 
patches solve my problem with the GemPC Card pcmcia reader
and cardos 4.3b 
together with opensc.

Can anybody push these patches forward to the pcsc
developer? Or do I have to 
subscribe to yet another mailinglist ?

  Wolfgang
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

Hello,

On 03/08/06, Wolfgang Glas <wolfgang.glasev-i.at> wrote:
> OK, I've checked the logs and it boiled down to a
problem, that a 2048 bit
> signature for cardos 4.3b is a 265 byte APDU to be
transmitted to the card.
>
> The maximal buffer in pcsc-lite has been configured to
264 and the maximal
> buffer in the accompanying ccid driver has been set to
263(!). The attached
> patches solve my problem with the GemPC Card pcmcia
reader and cardos 4.3b
> together with opensc.
>
> Can anybody push these patches forward to the pcsc
developer? Or do I have to
> subscribe to yet another mailinglist ?

You do not have to subscribe to another mailing list. I am
the
maintainer of pcsc-lite and the CCID driver.

I do not agree with your patches. I guess your card is a T=1
one (can
you send the card ATR please?) so the modifications you made
work.

The new version of pcsc-lite and CCID driver will support
extended
APDU out of the box (without special configuration) so this
problem
will be solved (in an elegant way).

Bye,

-- 
  Dr. Ludovic Rousseau
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

Am Donnerstag, 3. August 2006 22:57 schrieb Ludovic
Rousseau:
> Hello,
>
> On 03/08/06, Wolfgang Glas <wolfgang.glasev-i.at> wrote:
> > OK, I've checked the logs and it boiled down to a
problem, that a 2048
> > bit signature for cardos 4.3b is a 265 byte APDU
to be transmitted to the
> > card.
> >
> > The maximal buffer in pcsc-lite has been
configured to 264 and the
> > maximal buffer in the accompanying ccid driver has
been set to 263(!).
> > The attached patches solve my problem with the
GemPC Card pcmcia reader
> > and cardos 4.3b together with opensc.
> >
> > Can anybody push these patches forward to the pcsc
developer? Or do I
> > have to subscribe to yet another mailinglist ?
>
> You do not have to subscribe to another mailing list. I
am the
> maintainer of pcsc-lite and the CCID driver.

That's fine 

> I do not agree with your patches. I guess your card is
a T=1 one (can
> you send the card ATR please?) so the modifications you
made work.

I must admit, that I just played around up to the point
where I had a working 
setup. At least the problem, that ccid and pcsc-lite are
imposing a different 
size limit (263 vs. 264) on the transmitted APDU should IMHO
be clarified.

My card is a Siemens CardOS 4.3b

*******************************
# opensc-tool -a
3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74
# cardos-info
Info : CardOS V4.3B (C) Siemens AG 1994-2004
Chip type: 123
Serial number: 25 72 d5 07 11 1b
Full prom dump:
33 66 00 40 EB EB EB EB 7B FF 25 72 D5 07 11 1B 3f.....{.%r....
00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
................
OS Version: 200.8 (that's CardOS M4.3b)
Current life cycle: 32 (administration)
Security Status of current DF:
Free memory : 1024
ATR Status: 0x0 ROM-ATR
Packages installed:
E1 09 01 04 13 02 C8 08 8F 01 01 ...........
Ram size: 4, Eeprom size: 32, cpu type: 66, chip config: 63
Free eeprom memory: 20909
System keys: PackageLoadKey (version 0x00, retries 10)
System keys: StartKey (version 0xff, retries 10)
Path to current DF:
/home/wglas/hpgs-old/testsuite/adobe >                 
*******************************

Note: This card works only with the latest opensc
SVN trunk.

> The new version of pcsc-lite and CCID driver will
support extended
> APDU out of the box (without special configuration) so
this problem
> will be solved (in an elegant way).

I've seen these options, but I was unsure, whether these
options would break 
my setup. How do I activate them exactly, BTW ? 

  Best regards,

    Wolfgang
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

On 04/08/06, Wolfgang Glas <wolfgang.glasev-i.at> wrote:
> Am Donnerstag, 3. August 2006 22:57 schrieb Ludovic
> > I do not agree with your patches. I guess your
card is a T=1 one (can
> > you send the card ATR please?) so the
modifications you made work.
>
> I must admit, that I just played around up to the point
where I had a working
> setup.

You can remove the patch for ccid and it should work. Can
you confirm?

> At least the problem, that ccid and pcsc-lite are
imposing a different
> size limit (263 vs. 264) on the transmitted APDU should
IMHO be clarified.

The value 263 in the CCID driver comes from the reuse of
code from the
ifdgempc driver [1]. This value should in fact be 262 and is
now
corrected in revision 2123. Thanks for the bug report.

> # opensc-tool -a
> 3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74

It is a T=1 card.

> > The new version of pcsc-lite and CCID driver will
support extended
> > APDU out of the box (without special
configuration) so this problem
> > will be solved (in an elegant way).
>
> I've seen these options, but I was unsure, whether
these options would break
> my setup. How do I activate them exactly, BTW ?

Do not play with that since it will disappear in the next
version of pcsc-lite.

Bye,

[1] 
http://ludovic.rousseau.free.fr/softwares/ifd-GemPC/

-- 
  Dr. Ludovic Rousseau
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

Am Montag, 7. August 2006 12:07 schrieb Ludovic Rousseau:
> On 04/08/06, Wolfgang Glas <wolfgang.glasev-i.at> wrote:
> > Am Donnerstag, 3. August 2006 22:57 schrieb
Ludovic
> >
> > > I do not agree with your patches. I guess
your card is a T=1 one (can
> > > you send the card ATR please?) so the
modifications you made work.
> >
> > I must admit, that I just played around up to the
point where I had a
> > working setup.
>
> You can remove the patch for ccid and it should work.
Can you confirm?

No, unfortunately, I needed both patches in order to get the
setup 
operational.

The pcsc-lite patch avoids the error condition in

pcsc-lite-1.3.1/src/winscard.c:1432

	if (cbSendLength > MAX_BUFFER_SIZE)
	{
		return SCARD_E_INSUFFICIENT_BUFFER;
	}


After working around this error by increasing
MAX_BUFFER_SIZE by my first 
patch, I came across the check in

ccid-1.0.1/src/commands.c:726

	/* command length too big for CCID driver? */
	if (tx_length > CMD_BUF_SIZE)


This check is then circumvented by my second patch.

> > At least the problem, that ccid and pcsc-lite are
imposing a different
> > size limit (263 vs. 264) on the transmitted APDU
should IMHO be
> > clarified.
>
> The value 263 in the CCID driver comes from the reuse
of code from the
> ifdgempc driver [1]. This value should in fact be 262
and is now
> corrected in revision 2123. Thanks for the bug report.
>
> > # opensc-tool -a
> > 3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74
>
> It is a T=1 card.
>
> > > The new version of pcsc-lite and CCID driver
will support extended
> > > APDU out of the box (without special
configuration) so this problem
> > > will be solved (in an elegant way).
> >
> > I've seen these options, but I was unsure,
whether these options would
> > break my setup. How do I activate them exactly,
BTW ?
>
> Do not play with that since it will disappear in the
next version of
> pcsc-lite.

That is good news, I can test any prereleases with my
2048bit setup, if you 
just send me small e-mail.

Another amendement to the ccid package would be to enable
the installation of 
the serial gempc driver either by default or by a
configure-option, because 
the use of an extra install-rule is not very convenient.
Since the GemPC card 
is going to be a real frequent setup, because this PCMCIA
reader has an 
affordable price and is CCID-compliant, I would opt for
installing the serial 
version of the ccid driver by default.

  Thanks for your help,

   Wolfgang
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

On 07/08/06, Wolfgang Glas <wolfgang.glasev-i.at> wrote:
> Am Montag, 7. August 2006 12:07 schrieb Ludovic
Rousseau:
> > You can remove the patch for ccid and it should
work. Can you confirm?
>
> No, unfortunately, I needed both patches in order to
get the setup
> operational.
>
> The pcsc-lite patch avoids the error condition in
>
> pcsc-lite-1.3.1/src/winscard.c:1432
>
>         if (cbSendLength > MAX_BUFFER_SIZE)
>         {
>                 return SCARD_E_INSUFFICIENT_BUFFER;
>         }
>
>
> After working around this error by increasing
MAX_BUFFER_SIZE by my first
> patch, I came across the check in
>
> ccid-1.0.1/src/commands.c:726
>
>         /* command length too big for CCID driver? */
>         if (tx_length > CMD_BUF_SIZE)
>
>
> This check is then circumvented by my second patch.

I see. This part of the code changed since version 1.0.1 of
the
driver. The new version does not have this test at this
place.

> > Do not play with that since it will disappear in
the next version of
> > pcsc-lite.
>
> That is good news, I can test any prereleases with my
2048bit setup, if you
> just send me small e-mail.

You can get the latest version using the subversion
repository [1]. I
will try to generate a snapshot this evening.

> Another amendement to the ccid package would be to
enable the installation of
> the serial gempc driver either by default or by a
configure-option, because
> the use of an extra install-rule is not very
convenient. Since the GemPC card
> is going to be a real frequent setup, because this
PCMCIA reader has an
> affordable price and is CCID-compliant, I would opt for
installing the serial
> version of the ccid driver by default.

You should be able to install the serial CCID driver by
doing:
$ configure
$ make
$ cd src
$ make install_ccidtwin

or maybe you are talking about something else?

Bye,

[1] http://svn.alioth.debia
n.org/ (project pcsclite)

-- 
  Dr. Ludovic Rousseau
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

Am Montag, 7. August 2006 13:45 schrieb Ludovic Rousseau:
> On 07/08/06, Wolfgang Glas <wolfgang.glasev-i.at> wrote:
> > Am Montag, 7. August 2006 12:07 schrieb Ludovic
Rousseau:
> > > You can remove the patch for ccid and it
should work. Can you confirm?
> >
> > No, unfortunately, I needed both patches in order
to get the setup
> > operational.

[snip]

> I see. This part of the code changed since version
1.0.1 of the
> driver. The new version does not have this test at this
place.

OK, that's good. I will test the new version.

> > > Do not play with that since it will disappear
in the next version of
> > > pcsc-lite.
> >
> > That is good news, I can test any prereleases with
my 2048bit setup, if
> > you just send me small e-mail.
>
> You can get the latest version using the subversion
repository [1]. I
> will try to generate a snapshot this evening.

I will check the snapshot.

> > Another amendement to the ccid package would be to
enable the
> > installation of the serial gempc driver either by
default or by a
> > configure-option, because the use of an extra
install-rule is not very
> > convenient. Since the GemPC card is going to be a
real frequent setup,
> > because this PCMCIA reader has an affordable price
and is CCID-compliant,
> > I would opt for installing the serial version of
the ccid driver by
> > default.
>
> You should be able to install the serial CCID driver by
doing:
> $ configure
> $ make
> $ cd src
> $ make install_ccidtwin
>
> or maybe you are talking about something else?

I know this, the point in  my quotation was, that the
alternative install rule 
(make install_ccidtwin) is a very inconvenient solution.
IMHO the ccidtwin 
driver will become more and more important, so this driver
should just be 
installed in the main install rule. If that is not feasible
for you, I would 
prefer to find a configure option:

./configure --enable-ccidtwin
make install

  Best regards, Wolfgang
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user

On 07/08/06, Wolfgang Glas <wolfgang.glasev-i.at> wrote:
> Am Montag, 7. August 2006 13:45 schrieb Ludovic
Rousseau:
> > You can get the latest version using the
subversion repository [1]. I
> > will try to generate a snapshot this evening.
>
> I will check the snapshot.

They are now available on [1].

> I know this, the point in  my quotation was, that the
alternative install rule
> (make install_ccidtwin) is a very inconvenient
solution. IMHO the ccidtwin
> driver will become more and more important, so this
driver should just be
> installed in the main install rule. If that is not
feasible for you, I would
> prefer to find a configure option:
>
> ./configure --enable-ccidtwin
> make install

That may be a good solution. I will look at it.

Bye,

[1] 
http://ludovic.rousseau.free.fr/softwares/pcsc-lite/

-- 
  Dr. Ludovic Rousseau
_______________________________________________
opensc-user mailing list
opensc-userlists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-
user