CCID-Pinpad-Problems

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

CCID-Pinpad-Problems

Martin Preuss-2
Hi,

This problem might more be related to the CCID driver, but since its
developers seem to hang out here (and the code I'm talking about is part of
OpensC as well) I'd like to ask here.

I want to perform the verification of a PIN with my Kobol Kaan Advanced. It
already works for ASCII-encoded PINs, however, GLP-Pins do not work (I had
that problem a long time ago with the SCR532 as well, but couldn't solve it).

Last time I asked I was directed towards the examples in OpenSC and in the
CCID driver. However, these examples only verify ASCII pins, and as I said
before *that* already works for me.

What would be the correct parameters for a GLP pin? I tried this
(PIN_VERIFY_STRUCTURE):

00 00 41 48 04 08 04 02 00 00 00 00 00 00 00 0d
00 00 00 00 20 00 81 08 28 ff ff ff ff ff ff ff

This should mean: Pin is BCD-style, pin starts at bit 4,
pin-length is stored at bit 4 (4 bits in length), the total pin block size is
8 bytes, minimum pin length (in digits) is 4, maximum pin length (in digits)
is 8.

According to the CCID specs (and your code in OpenSC) this should be just
fine, but it always returns SW1=0x6a SW2=0x80.

Do I miss something here?


regards
Martin Preuss

PS: GLP pin example for pin "12345": 0x25, 0x12, 0x34, 0x5f, 0xff, 0xff, 0xff,
0xff

--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Paljak
If you talk about pinpad code in opensc, let me know of:
card and protocol
pin info
opensc debug with relevant parts

I'll have a look at it (as well as do other related stuff) once I'll
be back in Estonia on the weekend,

M, on the road in spain.
On 12/8/05, Martin Preuss <[hidden email]> wrote:

> Hi,
>
> This problem might more be related to the CCID driver, but since its
> developers seem to hang out here (and the code I'm talking about is part of
> OpensC as well) I'd like to ask here.
>
> I want to perform the verification of a PIN with my Kobol Kaan Advanced. It
> already works for ASCII-encoded PINs, however, GLP-Pins do not work (I had
> that problem a long time ago with the SCR532 as well, but couldn't solve it).
>
> Last time I asked I was directed towards the examples in OpenSC and in the
> CCID driver. However, these examples only verify ASCII pins, and as I said
> before *that* already works for me.
>
> What would be the correct parameters for a GLP pin? I tried this
> (PIN_VERIFY_STRUCTURE):
>
> 00 00 41 48 04 08 04 02 00 00 00 00 00 00 00 0d
> 00 00 00 00 20 00 81 08 28 ff ff ff ff ff ff ff
>
> This should mean: Pin is BCD-style, pin starts at bit 4,
> pin-length is stored at bit 4 (4 bits in length), the total pin block size is
> 8 bytes, minimum pin length (in digits) is 4, maximum pin length (in digits)
> is 8.
>
> According to the CCID specs (and your code in OpenSC) this should be just
> fine, but it always returns SW1=0x6a SW2=0x80.
>
> Do I miss something here?
>
>
> regards
> Martin Preuss
>
> PS: GLP pin example for pin "12345": 0x25, 0x12, 0x34, 0x5f, 0xff, 0xff, 0xff,
> 0xff
>
> --
> "Things are only impossible until they're not"
>
> AqBanking - http://www.aquamaniac.de/aqbanking/
> LibChipcard - http://www.libchipcard.de/
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>


--
Martin Paljak
[hidden email]
http://martin.paljak.pri.ee/
+372.5156495 - phone
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Preuss-2
Hi,

On Thursday 08 December 2005 19:13, Martin Paljak wrote:
[...]
> If you talk about pinpad code in opensc, let me know of:
> card and protocol
> pin info
> opensc debug with relevant parts
[...]

I'm rather talking about the CCID code (which is also used in OpenCT as it
seems?).

I use the driver directly, i.e. not via PC/SC. So far this didn't produce any
problems, the only thing which doesn't work is the pin verification.

Before my tool asks for the pin it selects some DF and EF on the card, reads
some records from some EF and finally asks for the pin. Everything until that
point works flawlessly. Also, verifying the ASCII-encoded pin of another card
works as well.

The only thing which doesn't work is the pin verification of a GLP-pin. As far
as I can see such a pin is also used in belpic cards. Is there somebody who
could verify the pin of such a card with a Kobil Kaan Advance?

The same problem applies to my SCM SPR532: I also get SW1=0x6a and SW2=0x80
("inconsistent parameters in data field").

In addition, the SPR532 has some other errors: When sending the
PIN_VERIFICATION stuff to the reader I always get a 6 bytes response, which
looks like this:

xx xx SW1 SW2 xx

As you can see the response codes SW1 and SW2 aren't the last two bytes of the
response (which I would expect). This only happens with the Pin verification
command, all other commands work fine.

To make it clear: After sending a command either to my Kobil or to the SPR 532
the reader really asks for the pin, and it does sound an error after I press
the "OK" button on the reader. So it seems the reader really knows what it is
expected to do, but it then seems that the reader assembles a bad APDU for
the card...

Verifying the pin with a non-CCID reader works, too.

Please have a look at the attached log file: It shows what's been sent to the
reader and what the reader returns. The ATR of the card is

3b ff 18 00 ff 81 31 3c 45 65 63 0d 02 31 02 50
00 10 39 13 50 10 04 10 d5

Firmware:
- Kobil Kaan Advanced: V1.02, UpdateLevel 40 (newest)
- SCM SPR532: 5.07beta

CCID: SVN Revision 150 (from
http://www.opensc.org/svn/ideelabor/trunk/mp/ccid)


regards
Martin Preuss

--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

auto3-ko_kaan_advanced_usb.log.bz2 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Preuss-2
In reply to this post by Martin Paljak
Hi,

just an update: The data needed for Kobil Kaan Advanced with FPIN2 is this:

00 00 89 47 04 08 04 02 00 00 00 00 00 00 00 0d
00 00 00 00 20 00 81 08 20 ff ff ff ff ff ff ff

As you can see the number of bytes for the pin in bmPINBlockString needs to be
7 (->47), so obviously the first byte doesn't count.

However, my SCM SPR 532 still doesn't like this data, it still returns
SW1=0x6a SW2=80...

So it seems that CCID isn't implemented the same way in every reader's
firmware... (as the source code of the CCID driver suggests: There is some
special code for SPR532).


Regards
Martin


--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Paljak
I've been on the road for quite long time and all needed changes are
in ccid upstream, so use the ccid driver you get directly from alioth
svn or somewhere else.

m.

On 12/9/05, Martin Preuss <[hidden email]> wrote:

> Hi,
>
> just an update: The data needed for Kobil Kaan Advanced with FPIN2 is this:
>
> 00 00 89 47 04 08 04 02 00 00 00 00 00 00 00 0d
> 00 00 00 00 20 00 81 08 20 ff ff ff ff ff ff ff
>
> As you can see the number of bytes for the pin in bmPINBlockString needs to be
> 7 (->47), so obviously the first byte doesn't count.
>
> However, my SCM SPR 532 still doesn't like this data, it still returns
> SW1=0x6a SW2=80...
>
> So it seems that CCID isn't implemented the same way in every reader's
> firmware... (as the source code of the CCID driver suggests: There is some
> special code for SPR532).
>
>
> Regards
> Martin
>
>
> --
> "Things are only impossible until they're not"
>
> AqBanking - http://www.aquamaniac.de/aqbanking/
> LibChipcard - http://www.libchipcard.de/
>


--
Martin Paljak
[hidden email]
http://martin.paljak.pri.ee/
+372.5156495 - phone
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Preuss-2
Hi,

On Friday 09 December 2005 10:23, Martin Paljak wrote:
> I've been on the road for quite long time and all needed changes are
> in ccid upstream, so use the ccid driver you get directly from alioth
> svn or somewhere else.
[...]

I just tried the latest SVN snapshot of the CCID driver from PC/SC's svn ($Id
of src/ccid.c is 2005-11-29, so it seems to be rather new).

However, the problems are the same. I tried multiple formats (starting with
the one used for the Kobil reader), but the result is still the same: The
reader makes its error sound and the verification doesn't succeed...

Please find the log of a session with the SPR532 attached.


Regards
Martin

--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

auto1-ccid_scm_x32.log.bz2 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Preuss-2
Hi again,

On Friday 09 December 2005 13:44, Martin Preuss wrote:
[...]
> I just tried the latest SVN snapshot of the CCID driver from PC/SC's svn
> ($Id of src/ccid.c is 2005-11-29, so it seems to be rather new).
>
> However, the problems are the same. I tried multiple formats (starting with
> the one used for the Kobil reader), but the result is still the same: The
> reader makes its error sound and the verification doesn't succeed...
[...]

Just a summary of the previous log:

I'm sending the following data via IFDHControl (according to an example in the
CCID specs):
00 00 89 47 04 08 04 02 00 00 00 00 00 00 00 0d
00 00 00 00 20 00 81 08 28 ff ff ff ff ff ff ff

The function returns this data:
00 82 00 82

When sending exactly the same bytes to the Kobil Kaan Advanced (via the same
CCID driver) it succeeds and thus returns 0x90 0x00.

So it seems the SPR 532 doesn't handle this command the same way the Kobil
reader does... So much for "standards"...
The reader just works as it is supposed to up until the point when the APDU is
actually sent to the card...

The ATR of the card is still
3b ff 18 00 ff 81 31 3c 45 65 63 0d 02 31 02 50
00 10 90 05 35 00 04 10 1f
(German HBCI card, DDV1, also contains the GeldKarte application).

Also, I'm unable to verify the pin of a STARCOS card with the SPR532 (and
again, with the Kobil it works).


regards
Martin



--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Ludovic Rousseau
In reply to this post by Martin Preuss-2
On 08/12/05, Martin Preuss <[hidden email]> wrote:
> Hi,

Hello,

> In addition, the SPR532 has some other errors: When sending the
> PIN_VERIFICATION stuff to the reader I always get a 6 bytes response, which
> looks like this:
>
> xx xx SW1 SW2 xx
>
> As you can see the response codes SW1 and SW2 aren't the last two bytes of the
> response (which I would expect). This only happens with the Pin verification
> command, all other commands work fine.

The SPR532 is working at the TPDU level. What you got is a T=1 TPDU block.
The KAAN Advanced is working at the APDU level so you only get the SW.

You only see the difference when using a T=1 card.

I am not sure which CCID driver you are using. The one from OpenCT or
mine from [1]?

I will try to find some time to test with GLP-Pins format.

> Firmware:
> - Kobil Kaan Advanced: V1.02, UpdateLevel 40 (newest)

Where did you get the firmware update?

> - SCM SPR532: 5.07beta
>
> CCID: SVN Revision 150 (from
> http://www.opensc.org/svn/ideelabor/trunk/mp/ccid)

This is a copy of my driver, maybe with patches.

Bye,

[1] http://pcsclite.alioth.debian.org/ccid.html

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Preuss-2
Hi,

On Sunday 11 December 2005 19:48, Ludovic Rousseau wrote:
[...]
> I am not sure which CCID driver you are using. The one from OpenCT or
> mine from [1]?
[...]
I started with your driver (ccid-0.9.4, from [1]), and then tried the
SVN-Version from OpenSC an later the one from PC/SC
(svn://svn.debian.org/pcsclite/trunk/Drivers/ccid).

> I will try to find some time to test with GLP-Pins format.
[...]
Thank you very much.

>
> > Firmware:
> > - Kobil Kaan Advanced: V1.02, UpdateLevel 40 (newest)
>
> Where did you get the firmware update?
I got a brand new reader from Kobil which already ships with that firmware.
Anyway, the Kobil reader now works (I figured out what data to send), so the
only problem left is the one (well, actually two) with the SPR532, which does
not verify any pin on my system (with firmware 5.07beta, which is the only
one currently availabe from the SCM website).

[...]
> This is a copy of my driver, maybe with patches.
[...]
I thought so, however, the one from pcsclite seems to be more recent.


Thanks,
Martin


[1] http://pcsclite.alioth.debian.org/ccid.html

--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Ludovic Rousseau
In reply to this post by Martin Preuss-2
On 09/12/05, Martin Preuss <[hidden email]> wrote:

> Hi,
>
> just an update: The data needed for Kobil Kaan Advanced with FPIN2 is this:
>
> 00 00 89 47 04 08 04 02 00 00 00 00 00 00 00 0d
> 00 00 00 00 20 00 81 08 20 ff ff ff ff ff ff ff
>
> As you can see the number of bytes for the pin in bmPINBlockString needs to be
> 7 (->47), so obviously the first byte doesn't count.
>
> However, my SCM SPR 532 still doesn't like this data, it still returns
> SW1=0x6a SW2=80...
>
> So it seems that CCID isn't implemented the same way in every reader's
> firmware... (as the source code of the CCID driver suggests: There is some
> special code for SPR532).

I tried this frame and have some results.
Exactly I use:
    /* PC/SC v2.0.2 Part 10 PIN verification data structure */
    pin_verify -> bTimerOut = 0x00;
    pin_verify -> bTimerOut2 = 0x00;
    pin_verify -> bmFormatString = 0x89;
    pin_verify -> bmPINBlockString = 0x47;
    pin_verify -> bmPINLengthFormat = 0x04;
    pin_verify -> wPINMaxExtraDigit = HOST_TO_CCID_16(0x0408); /* Min Max */
    pin_verify -> bEntryValidationCondition = 0x02; /* validation key pressed */
    pin_verify -> bNumberMessage = 0x00;
    pin_verify -> wLangId = HOST_TO_CCID_16(0x0000);
    pin_verify -> bMsgIndex = 0x00;
    pin_verify -> bTeoPrologue[0] = 0x00;
    pin_verify -> bTeoPrologue[1] = 0x00;
    pin_verify -> bTeoPrologue[2] = 0x00;
    /* pin_verify -> ulDataLength = 0x00; we don't know the size yet */

    offset = 0;
    pin_verify -> abData[offset++] = 0x00;  /* CLA */
    pin_verify -> abData[offset++] = 0x20;  /* INS: VERIFY */
    pin_verify -> abData[offset++] = 0x00;  /* P1 */
    pin_verify -> abData[offset++] = 0x81;  /* P2 */
    pin_verify -> abData[offset++] = 0x08;  /* Lc: 8 data bytes */
    pin_verify -> abData[offset++] = 0xFF;  /* '0' */
    pin_verify -> abData[offset++] = 0xFF;  /* '0' */
    pin_verify -> abData[offset++] = 0xFF;  /* '0' */
    pin_verify -> abData[offset++] = 0xFF;  /* '0' */
    pin_verify -> abData[offset++] = 0xFF;  /* '\0' */
    pin_verify -> abData[offset++] = 0xFF;  /* '\0' */
    pin_verify -> abData[offset++] = 0xFF;  /* '\0' */
    pin_verify -> abData[offset++] = 0xFF;  /* '\0' */
    pin_verify -> ulDataLength = HOST_TO_CCID_32(offset);   /* APDU size */

I use a Java Card applet to store the APDU send by the reader to the
card and get it back. It is cheaper than an ISO 7816-3 communication
spy tool :-)
In all the tests I enter 12345678 as PIN code.

With a SPR532, Kobil KAAN advanced and Cherry ST-2000 the card
receives: 00 20 00 81 08 F8 12 34 56 78 FF FF FF

With your first CCID frame sample
    pin_verify -> bmFormatString = 0x41;
    pin_verify -> bmPINBlockString = 0x48;
I have different results with different readers.
With the SPR532: 00 20 00 81 08 08 12 34 56 FF FF FF FF
With the Kobil KAAN advanced: 00 20 00 81 08 F8 12 56 78 FF FF FF FF
With the Cherry ST-2000: 00 20 00 81 08 FF FF FF FF FF FF FF FF

I don't know what the correct PIN format is in your case. Is "00 20 00
81 08 F8 12 34 56 78 FF FF FF" OK for your card?

Bye,

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Preuss-2
Hi,

On Wednesday 14 December 2005 14:22, Ludovic Rousseau wrote:
> On 09/12/05, Martin Preuss <[hidden email]> wrote:
[...]
> I use a Java Card applet to store the APDU send by the reader to the
> card and get it back. It is cheaper than an ISO 7816-3 communication
> spy tool :-)
[...]
Nicely done :-)

> In all the tests I enter 12345678 as PIN code.
[...]
>With a SPR532, Kobil KAAN advanced and Cherry ST-2000 the card
>receives: 00 20 00 81 08 F8 12 34 56 78 FF FF FF
[...]
Hmm, could you please try with 0x20 as the first byte after Lc? That should
create the correct APDU for the card (see below).

If that is the resulting APDU the card receives then I'm still wondering why
the reader still sounds an error (without decrementing the error counter, so
there must still be something wrong...)

>
> With your first CCID frame sample
>     pin_verify -> bmFormatString = 0x41;
>     pin_verify -> bmPINBlockString = 0x48;
> I have different results with different readers.
> With the SPR532: 00 20 00 81 08 08 12 34 56 FF FF FF FF
[...]
You mean the SPR532 just discards the last two digits of the pin?
What version is your firmware? There seem to be some differences between 5.04
and 5.07beta anyway, because with the older version I always got 6 bytes of
data as a result of the command (including the 0x6a 0x80), and now I only get
4 bytes (see previous mail).

> With the Kobil KAAN advanced: 00 20 00 81 08 F8 12 56 78 FF FF FF FF
[...]
Yes, with the Kobil this seems to be working...

> With the Cherry ST-2000: 00 20 00 81 08 FF FF FF FF FF FF FF FF
[...]
Whoops, no pin at all?


> I don't know what the correct PIN format is in your case. Is "00 20 00
> 81 08 F8 12 34 56 78 FF FF FF" OK for your card?
[...]

The first nibble of the data should be 0x2, not 0xF, but the rest is just
fine. 00 20 00 81 08 28 12 34 56 78 FF FF FF is what I would send to the card
if the reader didn't have a keypad...


Regards
Martin


--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Ludovic Rousseau
On 14/12/05, Martin Preuss <[hidden email]> wrote:
> On Wednesday 14 December 2005 14:22, Ludovic Rousseau wrote:
> > On 09/12/05, Martin Preuss <[hidden email]> wrote:
> [...]
> > I use a Java Card applet to store the APDU send by the reader to the
> > card and get it back. It is cheaper than an ISO 7816-3 communication
> > spy tool :-)
> [...]
> Nicely done :-)

The source code of the Java Card applet is available at [1].

> > In all the tests I enter 12345678 as PIN code.
> [...]
> >With a SPR532, Kobil KAAN advanced and Cherry ST-2000 the card
> >receives: 00 20 00 81 08 F8 12 34 56 78 FF FF FF
> [...]
> Hmm, could you please try with 0x20 as the first byte after Lc? That should
> create the correct APDU for the card (see below).

I tried with 0x00 and got 0x08. So I expect to have 0x28 if I use 0x20.
I don't have access to the readers until Monday. You will have to be patient :-)

> If that is the resulting APDU the card receives then I'm still wondering why
> the reader still sounds an error (without decrementing the error counter, so
> there must still be something wrong...)

If the card reply something other than 0x9000 I think the reader will
sounds an error. What is the card answer in your case?

> > With your first CCID frame sample
> >     pin_verify -> bmFormatString = 0x41;
> >     pin_verify -> bmPINBlockString = 0x48;
> > I have different results with different readers.
> > With the SPR532: 00 20 00 81 08 08 12 34 56 FF FF FF FF
> [...]
> You mean the SPR532 just discards the last two digits of the pin?

Seems so.

> What version is your firmware? There seem to be some differences between 5.04
> and 5.07beta anyway, because with the older version I always got 6 bytes of
> data as a result of the command (including the 0x6a 0x80), and now I only get
> 4 bytes (see previous mail).

I can't confirm since I don't have the reader here but it should be
5.07 as noted in [2].

> > With the Kobil KAAN advanced: 00 20 00 81 08 F8 12 56 78 FF FF FF FF
> [...]
> Yes, with the Kobil this seems to be working...

Note that the 0x34 value disappeared between 0x12 and 0x56.

> > With the Cherry ST-2000: 00 20 00 81 08 FF FF FF FF FF FF FF FF
> [...]
> Whoops, no pin at all?

Yes.

> > I don't know what the correct PIN format is in your case. Is "00 20 00
> > 81 08 F8 12 34 56 78 FF FF FF" OK for your card?
> [...]
>
> The first nibble of the data should be 0x2, not 0xF, but the rest is just
> fine. 00 20 00 81 08 28 12 34 56 78 FF FF FF is what I would send to the card
> if the reader didn't have a keypad...

I will tell you if that works on Monday.

Bye,

[1] http://svn.debian.org/wsvn/pcsclite/trunk/HandlerTest/JavaCard/?rev=0&sc=0
[2] http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/readers/SPR532.txt?op=file&rev=0&sc=0

--
  Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Preuss-2
Hi,

On Wednesday 14 December 2005 21:04, Ludovic Rousseau wrote:
[...]
> > If that is the resulting APDU the card receives then I'm still wondering
> > why the reader still sounds an error (without decrementing the error
> > counter, so there must still be something wrong...)
>
> If the card reply something other than 0x9000 I think the reader will
> sounds an error. What is the card answer in your case?
[...]
With firmware 5.04 I always got xx xx xx 6a 80 xx (which means "invalid
arguments in data field"). With firmware 5.07x I get 00 82 00 82 (which
doesn't resemble any SW codes I know of).

My guess is that the card still returns 6a 80 but the reader transforms this
to the bytes seen above (I can't tell what the card returns to the reader, I
can only tell you what the reader returns to me) ... This leaves me kind of
confused...


Regards
Martin

--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Ludovic Rousseau
On 15/12/05, Martin Preuss <[hidden email]> wrote:
> With firmware 5.04 I always got xx xx xx 6a 80 xx (which means "invalid
> arguments in data field"). With firmware 5.07x I get 00 82 00 82 (which
> doesn't resemble any SW codes I know of).

00 82 00 82 is a TPDU block of T=1 protocol. It can be parsed as:
NAD = 0x00 (node address byte)
PCB = 0x82 (protocol control byte)
LEN = 0x00 (length)
EDC = 0x82 (check sum)

The PCB indicates it is a T=1 R-block and the error code is "other errors".
It is described in ISO 7816-3 chapter 0.9.3.

Something went wrong in the communication but I don't know what.

> My guess is that the card still returns 6a 80 but the reader transforms this
> to the bytes seen above (I can't tell what the card returns to the reader, I
> can only tell you what the reader returns to me) ... This leaves me kind of
> confused...

Maybe you should ask some help from SCM. Or try another pin pad reader
to see if you have the same result.

I don't know what else I can do, unless you send me a smart card so I
can reproduce the problem myself.

Bye,

--
  Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CCID-Pinpad-Problems

Martin Preuss-2
Hi,

On Thursday 15 December 2005 13:40, Ludovic Rousseau wrote:
[...]
> Maybe you should ask some help from SCM. Or try another pin pad reader
> to see if you have the same result.
[...]
Ok, I have a second reader here, so I will try, even with different firmware
versions.

> I don't know what else I can do, unless you send me a smart card so I
> can reproduce the problem myself.
[...]
I could send you a test card I use here, provided you send it back to me...


Regards
Martin Preuss

--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel