PINPAD quirks

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

PINPAD quirks

J.Witvliet

Hi all,

 

Perhaps someone can shed some light on this…

 

I’ve got a class-3 cardreader, a Xiring XI-sign and from pcsclite.allioth.debian.org/ccid I learned that it does not support extended-APDU’s

Also I’ve got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.

One of the cards works as desired, other three choke on it.

How come that one IS working? (I was expecting all-or-nothing)

 

Initially I suspected that “no  extended APDU” was to blame…

But I also got a class-2 cardreader, an omnikey-3621.

Here all cards work, so it must be something different.

 

Any other good recommendation (reiner SCT cyberjack perhaps?)

 

Hans

 

 


Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Dirk-Willem van Gulik

> I’ve got a class-3 cardreader, a Xiring XI-sign and from pcsclite.allioth.debian.org/ccid I learned that it does not support extended-APDU’s
> Also I’ve got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
> One of the cards works as desired, other three choke on it.
> How come that one IS working? (I was expecting all-or-nothing)
>  
> Initially I suspected that “no  extended APDU” was to blame…
> But I also got a class-2 cardreader, an omnikey-3621.
> Here all cards work, so it must be something different.

We’ve observed the same; but traced it to AET batches with non identical applets.

>  Any other good recommendation (reiner SCT cyberjack perhaps?)

We’ve found the old SPR532 to be one of the more accommodating with-pinpad readers; and really rather hard to wedge.

Dw.


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Douglas E Engert
In reply to this post by J.Witvliet


On 9/24/2014 10:44 AM, [hidden email] wrote:

> Hi all,
>
> Perhaps someone can shed some light on this…
>
> I’ve got a class-3 cardreader, a Xiring XI-sign and from pcsclite.allioth.debian.org/ccid I learned that it does not support extended-APDU’s
>
> Also I’ve got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
>
> One of the cards works as desired, other three choke on it.
>
> How come that one IS working? (I was expecting all-or-nothing)
>
> Initially I suspected that “no  extended APDU” was to blame…
>
> But I also got a class-2 cardreader, an omnikey-3621.
>
> Here all cards work, so it must be something different.
>
> Any other good recommendation (reiner SCT cyberjack perhaps?)

No, see discussion on:
  https://github.com/OpenSC/OpenSC/issues/285#issuecomment-56284775


> Hans
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en
> het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the
> message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

J.Witvliet
In reply to this post by J.Witvliet
Thanks for pointing to the thread. Be careful though, you wrote there:
"Try a supported pinpad reader." And "Before buying the next pin pad reader check:"  http://pcsclite.alioth.debian.org/ccid/section.html"
So I did....
The Xiring I'm using (0x0F14:0x0011) is classified as "works"
And the gemalto is in the section "should work"

Only limitations stated were: "does not not support extended APDU"
So I had a look at "Gemalto Ezio Shield, 08e6:34c2"
Also listed as "should work" and no restrictions regarding extended APDU
You know what? NONE of the cards works.
As long as I ask the content without logging in, I get the data, but when I do
 pkcs11-tool -O -l I briefly see prompting dashes on the display, and the pc says CKR_DEVICE_ERROR  (0x30)

So it seems to me that "works" and "should work" are slightly misleading.

Hans

-----Original Message-----
From: Douglas E Engert [mailto:[hidden email]]
Sent: woensdag 24 september 2014 23:00
To: [hidden email]
Subject: Re: [Opensc-devel] PINPAD quirks



On 9/24/2014 10:44 AM, [hidden email] wrote:

> Hi all,
>
> Perhaps someone can shed some light on this...
>
> I've got a class-3 cardreader, a Xiring XI-sign and from
> pcsclite.allioth.debian.org/ccid I learned that it does not support
> extended-APDU's
>
> Also I've got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
>
> One of the cards works as desired, other three choke on it.
>
> How come that one IS working? (I was expecting all-or-nothing)
>
> Initially I suspected that "no  extended APDU" was to blame...
>
> But I also got a class-2 cardreader, an omnikey-3621.
>
> Here all cards work, so it must be something different.
>
> Any other good recommendation (reiner SCT cyberjack perhaps?)

No, see discussion on:
  https://github.com/OpenSC/OpenSC/issues/285#issuecomment-56284775


> Hans
>
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ------------------------------------------------------------
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien
> u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>
> This message may contain information that is not intended for you. If
> you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>
>
> ----------------------------------------------------------------------
> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
> EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
> clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Douglas E Engert


On 9/25/2014 5:19 AM, [hidden email] wrote:
> Thanks for pointing to the thread. Be careful though, you wrote there:
> "Try a supported pinpad reader." And "Before buying the next pin pad reader check:"  http://pcsclite.alioth.debian.org/ccid/section.html"

That is your best source of information for the PCSC-Lite.

> So I did....
> The Xiring I'm using (0x0F14:0x0011) is classified as "works"
> And the gemalto is in the section "should work"
>
> Only limitations stated were: "does not not support extended APDU"
> So I had a look at "Gemalto Ezio Shield, 08e6:34c2"
> Also listed as "should work" and no restrictions regarding extended APDU
> You know what? NONE of the cards works.

PCSC, the CCID reader(and its driver), OpenSC and the card must work together.
PCSC Part10 standard by PCSC, CCID and OpenSC are what works today.


ISO pin commands standards by reader, opensc and card.
(Or some other standard command OpenSC and the reader can recognize so
the reader will modify it.)

The reader must recognize the verify command being passed to the card, and
modify it by replacing and padding the PIN bytes from the pinpad.

If the card is using non standard ISO verify command, then the combination
may not work.

What card are you using again?

You could also try the readers and cards on Windows 7 or 8, using the reader
and card vendors software to see if the combination is supported on Windows.
(i.e. without using OpenSC's minidriver.)


> As long as I ask the content without logging in, I get the data, but when I do
>   pkcs11-tool -O -l I briefly see prompting dashes on the display, and the pc says CKR_DEVICE_ERROR  (0x30)

An opensc debug trace would help.

>
> So it seems to me that "works" and "should work" are slightly misleading.
>
> Hans
>
> -----Original Message-----
> From: Douglas E Engert [mailto:[hidden email]]
> Sent: woensdag 24 september 2014 23:00
> To: [hidden email]
> Subject: Re: [Opensc-devel] PINPAD quirks
>
>
>
> On 9/24/2014 10:44 AM, [hidden email] wrote:
>> Hi all,
>>
>> Perhaps someone can shed some light on this...
>>
>> I've got a class-3 cardreader, a Xiring XI-sign and from
>> pcsclite.allioth.debian.org/ccid I learned that it does not support
>> extended-APDU's
>>
>> Also I've got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
>>
>> One of the cards works as desired, other three choke on it.
>>
>> How come that one IS working? (I was expecting all-or-nothing)
>>
>> Initially I suspected that "no  extended APDU" was to blame...
>>
>> But I also got a class-2 cardreader, an omnikey-3621.
>>
>> Here all cards work, so it must be something different.
>>
>> Any other good recommendation (reiner SCT cyberjack perhaps?)
>
> No, see discussion on:
>    https://github.com/OpenSC/OpenSC/issues/285#issuecomment-56284775
>
>
>> Hans
>>
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> ------------------------------------------------------------
>> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien
>> u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>>
>> This message may contain information that is not intended for you. If
>> you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>>
>>
>> ----------------------------------------------------------------------
>> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
>> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
>> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
>> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
>> EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
>> clktrk
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Andreas Schwier (ML)
In reply to this post by J.Witvliet
Hi Hans,

you are using the SafeSign PKCS#11 module ? As far as I know, OpenSC has
no support for the AET card.

We've been using the Reiner SCT cyberjack a couple of times and that one
works well.

Andreas

On 09/25/2014 12:19 PM, [hidden email] wrote:

> Thanks for pointing to the thread. Be careful though, you wrote there:
> "Try a supported pinpad reader." And "Before buying the next pin pad reader check:"  http://pcsclite.alioth.debian.org/ccid/section.html"
> So I did....
> The Xiring I'm using (0x0F14:0x0011) is classified as "works"
> And the gemalto is in the section "should work"
>
> Only limitations stated were: "does not not support extended APDU"
> So I had a look at "Gemalto Ezio Shield, 08e6:34c2"
> Also listed as "should work" and no restrictions regarding extended APDU
> You know what? NONE of the cards works.
> As long as I ask the content without logging in, I get the data, but when I do
>  pkcs11-tool -O -l I briefly see prompting dashes on the display, and the pc says CKR_DEVICE_ERROR  (0x30)
>
> So it seems to me that "works" and "should work" are slightly misleading.
>
> Hans
>
> -----Original Message-----
> From: Douglas E Engert [mailto:[hidden email]]
> Sent: woensdag 24 september 2014 23:00
> To: [hidden email]
> Subject: Re: [Opensc-devel] PINPAD quirks
>
>
>
> On 9/24/2014 10:44 AM, [hidden email] wrote:
>> Hi all,
>>
>> Perhaps someone can shed some light on this...
>>
>> I've got a class-3 cardreader, a Xiring XI-sign and from
>> pcsclite.allioth.debian.org/ccid I learned that it does not support
>> extended-APDU's
>>
>> Also I've got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
>>
>> One of the cards works as desired, other three choke on it.
>>
>> How come that one IS working? (I was expecting all-or-nothing)
>>
>> Initially I suspected that "no  extended APDU" was to blame...
>>
>> But I also got a class-2 cardreader, an omnikey-3621.
>>
>> Here all cards work, so it must be something different.
>>
>> Any other good recommendation (reiner SCT cyberjack perhaps?)
>
> No, see discussion on:
>   https://github.com/OpenSC/OpenSC/issues/285#issuecomment-56284775
>
>
>> Hans
>>
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> ------------------------------------------------------------
>> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien
>> u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>>
>> This message may contain information that is not intended for you. If
>> you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>>
>>
>> ----------------------------------------------------------------------
>> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
>> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
>> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
>> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
>> EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
>> clktrk
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>


--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Anders Rundgren-2
It will extremely interesting to see the smart card industry
coming up with an interoperable solution for WebCrypto:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop

Anders

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Ludovic Rousseau
In reply to this post by J.Witvliet
2014-09-25 12:19 GMT+02:00  <[hidden email]>:
> Thanks for pointing to the thread. Be careful though, you wrote there:
> "Try a supported pinpad reader." And "Before buying the next pin pad reader check:"  http://pcsclite.alioth.debian.org/ccid/section.html"
> So I did....
> The Xiring I'm using (0x0F14:0x0011) is classified as "works"
> And the gemalto is in the section "should work"
>
> Only limitations stated were: "does not not support extended APDU"
> So I had a look at "Gemalto Ezio Shield, 08e6:34c2"

http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x08E60x34C2
indicates: "Features: firewall, PIN Verification, PIN Modification"

> Also listed as "should work" and no restrictions regarding extended APDU
> You know what? NONE of the cards works.

The firewall in the reader will prevent any PIN verification that does
not go thought the reader pinpad. So even if an application is
malicious and wants to get the PIN without using the reader pinpad it
will fail.

> As long as I ask the content without logging in, I get the data, but when I do
>  pkcs11-tool -O -l I briefly see prompting dashes on the display, and the pc says CKR_DEVICE_ERROR  (0x30)

I guess it is a problem with the secure verify command.
An OpenSC log would help.

> So it seems to me that "works" and "should work" are slightly misleading.

If you find a limitation or bug in a reader just tell me and I will
update the reader description at
http://pcsclite.alioth.debian.org/ccid/

Regards,

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

J.Witvliet
In reply to this post by J.Witvliet
Hi Douglas, Andreas, Ludovic  and all who follow the thread.

I am aware that at least three parties are involved:
- the card reader
- the card itself, and more specifically the java-applet on it
- the driver that communicate with that applet.
As I used the AET-library, I wonder if it is relevant I ran the tests on Ubuntu-14.04 (32 bit), and have the default opensc-0.13.0 installed

To answer some questions firsts, I have several different java-cards using the safesign applet from AET.
I use the latest driver from AET, I'm not sure if it has been publically released, it's version 3.0.97.
But this behaviour I have detected already some years ago, at that moment we opted to restrict ourselves to class-1 readers.

I am very much aware of the fact that the problem very much likely resides in either the applet and/or the AET-driver.
But, I puzzles me that
1) one card (UZI) works properly in the Xiring reader, while others not (only difference between cards is perhaps a different version of the applet?)
2) neither cards work in the gemalto reader
3) all of them work in the omnikey reader

So, for obtaining logfiles I enables opensc-debug and pcscd-debug
I ran pkcs11-tool --module /usr/lib/libaetpkss.so.3 -l -O (or -t) while using
- Class-1 scm reader
- Class-2 omnikey
- Class-3 Xiring
- class-3 gemalto

Next I did the same for a AET-test-smart-card, I just prepared with tokenadmin.
(I might run into troubles if I put dumps of an MoD card on Internet :-)

I hope this summary explains my confusion,

Hans.

-----Original Message-----
From: Douglas E Engert [mailto:[hidden email]]
Sent: donderdag 25 september 2014 15:27
To: Witvliet, J, DMO/OPS/I&S/HIN; [hidden email]
Subject: Re: [Opensc-devel] PINPAD quirks



On 9/25/2014 5:19 AM, [hidden email] wrote:
> Thanks for pointing to the thread. Be careful though, you wrote there:
> "Try a supported pinpad reader." And "Before buying the next pin pad reader check:"  http://pcsclite.alioth.debian.org/ccid/section.html"

That is your best source of information for the PCSC-Lite.

> So I did....
> The Xiring I'm using (0x0F14:0x0011) is classified as "works"
> And the gemalto is in the section "should work"
>
> Only limitations stated were: "does not not support extended APDU"
> So I had a look at "Gemalto Ezio Shield, 08e6:34c2"
> Also listed as "should work" and no restrictions regarding extended
> APDU You know what? NONE of the cards works.

PCSC, the CCID reader(and its driver), OpenSC and the card must work together.
PCSC Part10 standard by PCSC, CCID and OpenSC are what works today.


ISO pin commands standards by reader, opensc and card.
(Or some other standard command OpenSC and the reader can recognize so the reader will modify it.)

The reader must recognize the verify command being passed to the card, and modify it by replacing and padding the PIN bytes from the pinpad.

If the card is using non standard ISO verify command, then the combination may not work.

What card are you using again?

You could also try the readers and cards on Windows 7 or 8, using the reader and card vendors software to see if the combination is supported on Windows.
(i.e. without using OpenSC's minidriver.)


> As long as I ask the content without logging in, I get the data, but when I do
>   pkcs11-tool -O -l I briefly see prompting dashes on the display, and
> the pc says CKR_DEVICE_ERROR  (0x30)

An opensc debug trace would help.

>
> So it seems to me that "works" and "should work" are slightly misleading.
>
> Hans
>
> -----Original Message-----
> From: Douglas E Engert [mailto:[hidden email]]
> Sent: woensdag 24 september 2014 23:00
> To: [hidden email]
> Subject: Re: [Opensc-devel] PINPAD quirks
>
>
>
> On 9/24/2014 10:44 AM, [hidden email] wrote:
>> Hi all,
>>
>> Perhaps someone can shed some light on this...
>>
>> I've got a class-3 cardreader, a Xiring XI-sign and from
>> pcsclite.allioth.debian.org/ccid I learned that it does not support
>> extended-APDU's
>>
>> Also I've got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
>>
>> One of the cards works as desired, other three choke on it.
>>
>> How come that one IS working? (I was expecting all-or-nothing)
>>
>> Initially I suspected that "no  extended APDU" was to blame...
>>
>> But I also got a class-2 cardreader, an omnikey-3621.
>>
>> Here all cards work, so it must be something different.
>>
>> Any other good recommendation (reiner SCT cyberjack perhaps?)
>
> No, see discussion on:
>    https://github.com/OpenSC/OpenSC/issues/285#issuecomment-56284775
>
>
>> Hans
>>
>> ---------------------------------------------------------------------
>> -
>> ---------------------------------------------------------------------
>> -
>> ------------------------------------------------------------
>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
>> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>>
>> This message may contain information that is not intended for you. If
>> you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>>
>>
>> ---------------------------------------------------------------------
>> -
>> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
>> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
>> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
>> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
>> EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
>> clktrk
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>
--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

uzi-in-gemalto-class3 (1M) Download Attachment
uzi-in-omnikey-class2 (1M) Download Attachment
uzi-in-scm-class1 (1M) Download Attachment
uzi-in-xiring-class3 (1M) Download Attachment
test-in-gemalto-class3 (97K) Download Attachment
test-in-omnikey-class2 (234K) Download Attachment
test-in-scm-class1 (211K) Download Attachment
test-in-xiring-class3 (103K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Andreas Schwier (ML)
Hi Hans,

it's the pkcs#11 module (AET module in your case) that needs to issue
the proper SCardControl statements to the PCSC Daemon and to the reader
firmware.

Unfortunately there are subtle incompatibilities in the way reader
manufacturer interpret the values from the PC/SC specs. It's very likely
that while it works in one set-up, it fails in another.

I couldn't even tell from the logs where the AET driver request PIN
verification from the reader (maybe Ludovic ?).

If you look at part10_build_verify_pin_block() in [1], you can see how
many parameters the PKCS#11 module must provide to the reader. Each card
might require a different set of parameter and each PIN PAD must support
all of them - Without solid interop test specification this is
impossible to achieve.

The only thing you can do is to define what you want and ask the vendor
(AET) or the community (us) to make it happen.

Andreas

[1]
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/reader-pcsc.c#L1309

On 09/26/2014 03:37 PM, [hidden email] wrote:

> Hi Douglas, Andreas, Ludovic  and all who follow the thread.
>
> I am aware that at least three parties are involved:
> - the card reader
> - the card itself, and more specifically the java-applet on it
> - the driver that communicate with that applet.
> As I used the AET-library, I wonder if it is relevant I ran the tests on Ubuntu-14.04 (32 bit), and have the default opensc-0.13.0 installed
>
> To answer some questions firsts, I have several different java-cards using the safesign applet from AET.
> I use the latest driver from AET, I'm not sure if it has been publically released, it's version 3.0.97.
> But this behaviour I have detected already some years ago, at that moment we opted to restrict ourselves to class-1 readers.
>
> I am very much aware of the fact that the problem very much likely resides in either the applet and/or the AET-driver.
> But, I puzzles me that
> 1) one card (UZI) works properly in the Xiring reader, while others not (only difference between cards is perhaps a different version of the applet?)
> 2) neither cards work in the gemalto reader
> 3) all of them work in the omnikey reader
>
> So, for obtaining logfiles I enables opensc-debug and pcscd-debug
> I ran pkcs11-tool --module /usr/lib/libaetpkss.so.3 -l -O (or -t) while using
> - Class-1 scm reader
> - Class-2 omnikey
> - Class-3 Xiring
> - class-3 gemalto
>
> Next I did the same for a AET-test-smart-card, I just prepared with tokenadmin.
> (I might run into troubles if I put dumps of an MoD card on Internet :-)
>
> I hope this summary explains my confusion,
>
> Hans.
>
> -----Original Message-----
> From: Douglas E Engert [mailto:[hidden email]]
> Sent: donderdag 25 september 2014 15:27
> To: Witvliet, J, DMO/OPS/I&S/HIN; [hidden email]
> Subject: Re: [Opensc-devel] PINPAD quirks
>
>
>
> On 9/25/2014 5:19 AM, [hidden email] wrote:
>> Thanks for pointing to the thread. Be careful though, you wrote there:
>> "Try a supported pinpad reader." And "Before buying the next pin pad reader check:"  http://pcsclite.alioth.debian.org/ccid/section.html"
>
> That is your best source of information for the PCSC-Lite.
>
>> So I did....
>> The Xiring I'm using (0x0F14:0x0011) is classified as "works"
>> And the gemalto is in the section "should work"
>>
>> Only limitations stated were: "does not not support extended APDU"
>> So I had a look at "Gemalto Ezio Shield, 08e6:34c2"
>> Also listed as "should work" and no restrictions regarding extended
>> APDU You know what? NONE of the cards works.
>
> PCSC, the CCID reader(and its driver), OpenSC and the card must work together.
> PCSC Part10 standard by PCSC, CCID and OpenSC are what works today.
>
>
> ISO pin commands standards by reader, opensc and card.
> (Or some other standard command OpenSC and the reader can recognize so the reader will modify it.)
>
> The reader must recognize the verify command being passed to the card, and modify it by replacing and padding the PIN bytes from the pinpad.
>
> If the card is using non standard ISO verify command, then the combination may not work.
>
> What card are you using again?
>
> You could also try the readers and cards on Windows 7 or 8, using the reader and card vendors software to see if the combination is supported on Windows.
> (i.e. without using OpenSC's minidriver.)
>
>
>> As long as I ask the content without logging in, I get the data, but when I do
>>   pkcs11-tool -O -l I briefly see prompting dashes on the display, and
>> the pc says CKR_DEVICE_ERROR  (0x30)
>
> An opensc debug trace would help.
>
>>
>> So it seems to me that "works" and "should work" are slightly misleading.
>>
>> Hans
>>
>> -----Original Message-----
>> From: Douglas E Engert [mailto:[hidden email]]
>> Sent: woensdag 24 september 2014 23:00
>> To: [hidden email]
>> Subject: Re: [Opensc-devel] PINPAD quirks
>>
>>
>>
>> On 9/24/2014 10:44 AM, [hidden email] wrote:
>>> Hi all,
>>>
>>> Perhaps someone can shed some light on this...
>>>
>>> I've got a class-3 cardreader, a Xiring XI-sign and from
>>> pcsclite.allioth.debian.org/ccid I learned that it does not support
>>> extended-APDU's
>>>
>>> Also I've got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
>>>
>>> One of the cards works as desired, other three choke on it.
>>>
>>> How come that one IS working? (I was expecting all-or-nothing)
>>>
>>> Initially I suspected that "no  extended APDU" was to blame...
>>>
>>> But I also got a class-2 cardreader, an omnikey-3621.
>>>
>>> Here all cards work, so it must be something different.
>>>
>>> Any other good recommendation (reiner SCT cyberjack perhaps?)
>>
>> No, see discussion on:
>>    https://github.com/OpenSC/OpenSC/issues/285#issuecomment-56284775
>>
>>
>>> Hans
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> ---------------------------------------------------------------------
>>> -
>>> ------------------------------------------------------------
>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
>>> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>>>
>>> This message may contain information that is not intended for you. If
>>> you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
>>> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
>>> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
>>> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
>>> EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
>>> clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

J.Witvliet
In reply to this post by J.Witvliet
Hi Andreas,

Sounds reasonable enough if neither combinations worked.
But one smartcard (the UZI) _does_works in the Xiring-cl3 and also the omnikey_cl2 (so applet+library+reader CAN work)
And my MoD-card work in the omnikey-cl2 but not in the Xiring-cl3 (only one variable: the reader)
And that working card+library fails when trying another class-3 reader, the gemalto-cl3 (again only one variable: the reader)

I'm surely not part of the SafeSign-fan-club, but regarding above situations, makes me wonder if I have a case at AET...

Hans

-----Original Message-----
From: Andreas Schwier [mailto:[hidden email]]
Sent: vrijdag 26 september 2014 15:57
To: [hidden email]
Subject: Re: [Opensc-devel] PINPAD quirks

Hi Hans,

it's the pkcs#11 module (AET module in your case) that needs to issue the proper SCardControl statements to the PCSC Daemon and to the reader firmware.

Unfortunately there are subtle incompatibilities in the way reader manufacturer interpret the values from the PC/SC specs. It's very likely that while it works in one set-up, it fails in another.

I couldn't even tell from the logs where the AET driver request PIN verification from the reader (maybe Ludovic ?).

If you look at part10_build_verify_pin_block() in [1], you can see how many parameters the PKCS#11 module must provide to the reader. Each card might require a different set of parameter and each PIN PAD must support all of them - Without solid interop test specification this is impossible to achieve.

The only thing you can do is to define what you want and ask the vendor
(AET) or the community (us) to make it happen.

Andreas

[1]
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/reader-pcsc.c#L1309

On 09/26/2014 03:37 PM, [hidden email] wrote:

> Hi Douglas, Andreas, Ludovic  and all who follow the thread.
>
> I am aware that at least three parties are involved:
> - the card reader
> - the card itself, and more specifically the java-applet on it
> - the driver that communicate with that applet.
> As I used the AET-library, I wonder if it is relevant I ran the tests
> on Ubuntu-14.04 (32 bit), and have the default opensc-0.13.0 installed
>
> To answer some questions firsts, I have several different java-cards using the safesign applet from AET.
> I use the latest driver from AET, I'm not sure if it has been publically released, it's version 3.0.97.
> But this behaviour I have detected already some years ago, at that moment we opted to restrict ourselves to class-1 readers.
>
> I am very much aware of the fact that the problem very much likely resides in either the applet and/or the AET-driver.
> But, I puzzles me that
> 1) one card (UZI) works properly in the Xiring reader, while others
> not (only difference between cards is perhaps a different version of
> the applet?)
> 2) neither cards work in the gemalto reader
> 3) all of them work in the omnikey reader
>
> So, for obtaining logfiles I enables opensc-debug and pcscd-debug I
> ran pkcs11-tool --module /usr/lib/libaetpkss.so.3 -l -O (or -t) while
> using
> - Class-1 scm reader
> - Class-2 omnikey
> - Class-3 Xiring
> - class-3 gemalto
>
> Next I did the same for a AET-test-smart-card, I just prepared with tokenadmin.
> (I might run into troubles if I put dumps of an MoD card on Internet
> :-)
>
> I hope this summary explains my confusion,
>
> Hans.
>
> -----Original Message-----
> From: Douglas E Engert [mailto:[hidden email]]
> Sent: donderdag 25 september 2014 15:27
> To: Witvliet, J, DMO/OPS/I&S/HIN; [hidden email]
> Subject: Re: [Opensc-devel] PINPAD quirks
>
>
>
> On 9/25/2014 5:19 AM, [hidden email] wrote:
>> Thanks for pointing to the thread. Be careful though, you wrote there:
>> "Try a supported pinpad reader." And "Before buying the next pin pad reader check:"  http://pcsclite.alioth.debian.org/ccid/section.html"
>
> That is your best source of information for the PCSC-Lite.
>
>> So I did....
>> The Xiring I'm using (0x0F14:0x0011) is classified as "works"
>> And the gemalto is in the section "should work"
>>
>> Only limitations stated were: "does not not support extended APDU"
>> So I had a look at "Gemalto Ezio Shield, 08e6:34c2"
>> Also listed as "should work" and no restrictions regarding extended
>> APDU You know what? NONE of the cards works.
>
> PCSC, the CCID reader(and its driver), OpenSC and the card must work together.
> PCSC Part10 standard by PCSC, CCID and OpenSC are what works today.
>
>
> ISO pin commands standards by reader, opensc and card.
> (Or some other standard command OpenSC and the reader can recognize so
> the reader will modify it.)
>
> The reader must recognize the verify command being passed to the card, and modify it by replacing and padding the PIN bytes from the pinpad.
>
> If the card is using non standard ISO verify command, then the combination may not work.
>
> What card are you using again?
>
> You could also try the readers and cards on Windows 7 or 8, using the reader and card vendors software to see if the combination is supported on Windows.
> (i.e. without using OpenSC's minidriver.)
>
>
>> As long as I ask the content without logging in, I get the data, but when I do
>>   pkcs11-tool -O -l I briefly see prompting dashes on the display,
>> and the pc says CKR_DEVICE_ERROR  (0x30)
>
> An opensc debug trace would help.
>
>>
>> So it seems to me that "works" and "should work" are slightly misleading.
>>
>> Hans
>>
>> -----Original Message-----
>> From: Douglas E Engert [mailto:[hidden email]]
>> Sent: woensdag 24 september 2014 23:00
>> To: [hidden email]
>> Subject: Re: [Opensc-devel] PINPAD quirks
>>
>>
>>
>> On 9/24/2014 10:44 AM, [hidden email] wrote:
>>> Hi all,
>>>
>>> Perhaps someone can shed some light on this...
>>>
>>> I've got a class-3 cardreader, a Xiring XI-sign and from
>>> pcsclite.allioth.debian.org/ccid I learned that it does not support
>>> extended-APDU's
>>>
>>> Also I've got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
>>>
>>> One of the cards works as desired, other three choke on it.
>>>
>>> How come that one IS working? (I was expecting all-or-nothing)
>>>
>>> Initially I suspected that "no  extended APDU" was to blame...
>>>
>>> But I also got a class-2 cardreader, an omnikey-3621.
>>>
>>> Here all cards work, so it must be something different.
>>>
>>> Any other good recommendation (reiner SCT cyberjack perhaps?)
>>
>> No, see discussion on:
>>    https://github.com/OpenSC/OpenSC/issues/285#issuecomment-56284775
>>
>>
>>> Hans
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> ------------------------------------------------------------
>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
>>> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>>>
>>> This message may contain information that is not intended for you.
>>> If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
>>> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box
>>> PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance?
>>> Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5
>>> with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
>>> clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>
>
>
> ----------------------------------------------------------------------
> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
> EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
> clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Ludovic Rousseau
In reply to this post by J.Witvliet
2014-09-26 15:37 GMT+02:00  <[hidden email]>:

> Hi Douglas, Andreas, Ludovic  and all who follow the thread.
>
> I am aware that at least three parties are involved:
> - the card reader
> - the card itself, and more specifically the java-applet on it
> - the driver that communicate with that applet.
> As I used the AET-library, I wonder if it is relevant I ran the tests on Ubuntu-14.04 (32 bit), and have the default opensc-0.13.0 installed
>
> To answer some questions firsts, I have several different java-cards using the safesign applet from AET.
> I use the latest driver from AET, I'm not sure if it has been publically released, it's version 3.0.97.
> But this behaviour I have detected already some years ago, at that moment we opted to restrict ourselves to class-1 readers.
>
> I am very much aware of the fact that the problem very much likely resides in either the applet and/or the AET-driver.
> But, I puzzles me that
> 1) one card (UZI) works properly in the Xiring reader, while others not (only difference between cards is perhaps a different version of the applet?)
> 2) neither cards work in the gemalto reader
> 3) all of them work in the omnikey reader

I had a look at the uzi-in-gemalto-class3 log file:

Sep 26 14:44:19 portege pcscd: ifdhandler.c:1360:IFDHControl()
ControlCode: 0x42330006, usb:08e6/34c2:libudev:0:/dev/bus/usb/002/003
(lun: 10000)
Sep 26 14:44:19 portege pcscd: Control TxBuffer: 1E 1E 82 08 00 08 04
03 01 00 00 00 00 00 00 0D 00 00 00 00 20 00 82 08 00 00 00 00 00 00
00 00
Sep 26 14:44:19 portege pcscd: commands.c:1413:CCID_Receive error on byte 17
Sep 26 14:44:19 portege pcscd: Control RxBuffer:

The PKCS#11 lib is asking a secure verify PIN.
The reader complains about byte 17 in the command.
Byte 17 is bEntryValidationCondition and it is set to 00.

The bEntryValidationCondition is defined as:
The value is a bit wise OR operation.
01h Max size reached
02h Validation key pressed
04h Timeout occurred

So a value of 00 is rejected by the Gemalto reader. What should be
considered as a validation condition?

The problem is that different readers may not accept all possible
values. I think the (old) Gemalto reader will only accept 02.

I proposed an evolution to the PC/SCv2 part 10 specification to allow
the application to know what bEntryValidationCondition value is
supported by a reader. See
http://ludovicrousseau.blogspot.fr/2010/05/how-to-know-pin-sizes-supported-by.html

My CCID driver has some support of Gemalto readers.
See also http://ludovicrousseau.blogspot.fr/2014/02/new-version-of-libccid-1415.html

You may ask AET to improve their PKCS#11 library to use the mechanism
I described in my blog.


>From uzi-in-xiring-class3:
Sep 26 14:42:33 portege pcscd: ifdhandler.c:1360:IFDHControl()
ControlCode: 0x42330006, usb:0f14/0011:libudev:0:/dev/bus/usb/002/013
(lun: 0)
Sep 26 14:42:33 portege pcscd: Control TxBuffer: 1E 1E 82 08 00 08 04
03 01 00 00 00 00 00 00 0D 00 00 00 00 20 00 82 08 00 00 00 00 00 00
00 00
Sep 26 14:42:40 portege pcscd: Control RxBuffer: 90 00
Secure verify PIN worked

>From test-in-xiring-class3:
Sep 26 15:15:59 portege pcscd: ifdhandler.c:1360:IFDHControl()
ControlCode: 0x42330006, usb:0f14/0011:libudev:0:/dev/bus/usb/002/026
(lun: 0)
Sep 26 15:15:59 portege pcscd: Control TxBuffer: 1E 1E 82 0F 00 0F 04
03 01 00 00 00 00 00 00 14 00 00 00 01 20 00 03 0F 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Sep 26 15:15:59 portege pcscd: Control RxBuffer: 6B 80

The reader (or card) returned 6B 80.
I could not find what 6B 80 is for 7816-4

Bye,

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Andreas Schwier (ML)
In reply to this post by J.Witvliet
But maybe the AET driver has a "quirks" mode, where depending on the
reader name different SCardControl statements and PIN blocks are used ?
Any maybe those fail for your specific applet or reader firmware version ?

We had a similar issue with Reiner SCT cyberjack that would report an
error if we specified the maximum pin length to 16. As the reader only
supports a 15 digit PIN maximum, it gave an error rather than allowing
the user to enter up to 15 digits. Other readers would just ignore that
parameter.

It's really a mess, as applet (or more precise VERIFY APDU format),
reader firmware and PKCS#11 module must meet at their interface. That
combined with different applet, different module and different reader
firmware versions is a recipe for disaster.

Isn't there a reader matrix from AET that defines which combinations are
working ?

Andreas

On 09/26/2014 04:53 PM, [hidden email] wrote:

> Hi Andreas,
>
> Sounds reasonable enough if neither combinations worked.
> But one smartcard (the UZI) _does_works in the Xiring-cl3 and also the omnikey_cl2 (so applet+library+reader CAN work)
> And my MoD-card work in the omnikey-cl2 but not in the Xiring-cl3 (only one variable: the reader)
> And that working card+library fails when trying another class-3 reader, the gemalto-cl3 (again only one variable: the reader)
>
> I'm surely not part of the SafeSign-fan-club, but regarding above situations, makes me wonder if I have a case at AET...
>
> Hans
>
> -----Original Message-----
> From: Andreas Schwier [mailto:[hidden email]]
> Sent: vrijdag 26 september 2014 15:57
> To: [hidden email]
> Subject: Re: [Opensc-devel] PINPAD quirks
>
> Hi Hans,
>
> it's the pkcs#11 module (AET module in your case) that needs to issue the proper SCardControl statements to the PCSC Daemon and to the reader firmware.
>
> Unfortunately there are subtle incompatibilities in the way reader manufacturer interpret the values from the PC/SC specs. It's very likely that while it works in one set-up, it fails in another.
>
> I couldn't even tell from the logs where the AET driver request PIN verification from the reader (maybe Ludovic ?).
>
> If you look at part10_build_verify_pin_block() in [1], you can see how many parameters the PKCS#11 module must provide to the reader. Each card might require a different set of parameter and each PIN PAD must support all of them - Without solid interop test specification this is impossible to achieve.
>
> The only thing you can do is to define what you want and ask the vendor
> (AET) or the community (us) to make it happen.
>
> Andreas
>
> [1]
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/reader-pcsc.c#L1309
>
> On 09/26/2014 03:37 PM, [hidden email] wrote:
>> Hi Douglas, Andreas, Ludovic  and all who follow the thread.
>>
>> I am aware that at least three parties are involved:
>> - the card reader
>> - the card itself, and more specifically the java-applet on it
>> - the driver that communicate with that applet.
>> As I used the AET-library, I wonder if it is relevant I ran the tests
>> on Ubuntu-14.04 (32 bit), and have the default opensc-0.13.0 installed
>>
>> To answer some questions firsts, I have several different java-cards using the safesign applet from AET.
>> I use the latest driver from AET, I'm not sure if it has been publically released, it's version 3.0.97.
>> But this behaviour I have detected already some years ago, at that moment we opted to restrict ourselves to class-1 readers.
>>
>> I am very much aware of the fact that the problem very much likely resides in either the applet and/or the AET-driver.
>> But, I puzzles me that
>> 1) one card (UZI) works properly in the Xiring reader, while others
>> not (only difference between cards is perhaps a different version of
>> the applet?)
>> 2) neither cards work in the gemalto reader
>> 3) all of them work in the omnikey reader
>>
>> So, for obtaining logfiles I enables opensc-debug and pcscd-debug I
>> ran pkcs11-tool --module /usr/lib/libaetpkss.so.3 -l -O (or -t) while
>> using
>> - Class-1 scm reader
>> - Class-2 omnikey
>> - Class-3 Xiring
>> - class-3 gemalto
>>
>> Next I did the same for a AET-test-smart-card, I just prepared with tokenadmin.
>> (I might run into troubles if I put dumps of an MoD card on Internet
>> :-)
>>
>> I hope this summary explains my confusion,
>>
>> Hans.
>>
>> -----Original Message-----
>> From: Douglas E Engert [mailto:[hidden email]]
>> Sent: donderdag 25 september 2014 15:27
>> To: Witvliet, J, DMO/OPS/I&S/HIN; [hidden email]
>> Subject: Re: [Opensc-devel] PINPAD quirks
>>
>>
>>
>> On 9/25/2014 5:19 AM, [hidden email] wrote:
>>> Thanks for pointing to the thread. Be careful though, you wrote there:
>>> "Try a supported pinpad reader." And "Before buying the next pin pad reader check:"  http://pcsclite.alioth.debian.org/ccid/section.html"
>>
>> That is your best source of information for the PCSC-Lite.
>>
>>> So I did....
>>> The Xiring I'm using (0x0F14:0x0011) is classified as "works"
>>> And the gemalto is in the section "should work"
>>>
>>> Only limitations stated were: "does not not support extended APDU"
>>> So I had a look at "Gemalto Ezio Shield, 08e6:34c2"
>>> Also listed as "should work" and no restrictions regarding extended
>>> APDU You know what? NONE of the cards works.
>>
>> PCSC, the CCID reader(and its driver), OpenSC and the card must work together.
>> PCSC Part10 standard by PCSC, CCID and OpenSC are what works today.
>>
>>
>> ISO pin commands standards by reader, opensc and card.
>> (Or some other standard command OpenSC and the reader can recognize so
>> the reader will modify it.)
>>
>> The reader must recognize the verify command being passed to the card, and modify it by replacing and padding the PIN bytes from the pinpad.
>>
>> If the card is using non standard ISO verify command, then the combination may not work.
>>
>> What card are you using again?
>>
>> You could also try the readers and cards on Windows 7 or 8, using the reader and card vendors software to see if the combination is supported on Windows.
>> (i.e. without using OpenSC's minidriver.)
>>
>>
>>> As long as I ask the content without logging in, I get the data, but when I do
>>>   pkcs11-tool -O -l I briefly see prompting dashes on the display,
>>> and the pc says CKR_DEVICE_ERROR  (0x30)
>>
>> An opensc debug trace would help.
>>
>>>
>>> So it seems to me that "works" and "should work" are slightly misleading.
>>>
>>> Hans
>>>
>>> -----Original Message-----
>>> From: Douglas E Engert [mailto:[hidden email]]
>>> Sent: woensdag 24 september 2014 23:00
>>> To: [hidden email]
>>> Subject: Re: [Opensc-devel] PINPAD quirks
>>>
>>>
>>>
>>> On 9/24/2014 10:44 AM, [hidden email] wrote:
>>>> Hi all,
>>>>
>>>> Perhaps someone can shed some light on this...
>>>>
>>>> I've got a class-3 cardreader, a Xiring XI-sign and from
>>>> pcsclite.allioth.debian.org/ccid I learned that it does not support
>>>> extended-APDU's
>>>>
>>>> Also I've got four javacards, all equipped with the SafeSign-Identity-Client applet from AET.
>>>>
>>>> One of the cards works as desired, other three choke on it.
>>>>
>>>> How come that one IS working? (I was expecting all-or-nothing)
>>>>
>>>> Initially I suspected that "no  extended APDU" was to blame...
>>>>
>>>> But I also got a class-2 cardreader, an omnikey-3621.
>>>>
>>>> Here all cards work, so it must be something different.
>>>>
>>>> Any other good recommendation (reiner SCT cyberjack perhaps?)
>>>
>>> No, see discussion on:
>>>    https://github.com/OpenSC/OpenSC/issues/285#issuecomment-56284775
>>>
>>>
>>>> Hans
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> ------------------------------------------------------------
>>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
>>>> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
>>>>
>>>> This message may contain information that is not intended for you.
>>>> If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
>>>> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box
>>>> PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance?
>>>> Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5
>>>> with EventLog Analyzer
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
>>>> clktrk
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>
>>
>>
>>
>> ----------------------------------------------------------------------
>> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog
>> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
>> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
>> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
>> EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
>> clktrk
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>
>


--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

J.Witvliet
In reply to this post by J.Witvliet
Thanks Ludovic, That explains  quite a bit.
Funny thing with the Gemalto is that you don't even got a chance to press anything at all, it returns within a second.
Regarding AET, I will certainly pit this to their attention.
Perhaps as contract renegotiation are ongoing, they might be willing to listen this time...

Many thanks for all of your time!

-----Original Message-----
I had a look at the uzi-in-gemalto-class3 log file:

Sep 26 14:44:19 portege pcscd: ifdhandler.c:1360:IFDHControl()
ControlCode: 0x42330006, usb:08e6/34c2:libudev:0:/dev/bus/usb/002/003
(lun: 10000)
Sep 26 14:44:19 portege pcscd: Control TxBuffer: 1E 1E 82 08 00 08 04
03 01 00 00 00 00 00 00 0D 00 00 00 00 20 00 82 08 00 00 00 00 00 00
00 00
Sep 26 14:44:19 portege pcscd: commands.c:1413:CCID_Receive error on byte 17 Sep 26 14:44:19 portege pcscd: Control RxBuffer:

The PKCS#11 lib is asking a secure verify PIN.
The reader complains about byte 17 in the command.
Byte 17 is bEntryValidationCondition and it is set to 00.

The bEntryValidationCondition is defined as:
The value is a bit wise OR operation.
01h Max size reached
02h Validation key pressed
04h Timeout occurred

So a value of 00 is rejected by the Gemalto reader. What should be considered as a validation condition?

The problem is that different readers may not accept all possible values. I think the (old) Gemalto reader will only accept 02.

I proposed an evolution to the PC/SCv2 part 10 specification to allow the application to know what bEntryValidationCondition value is supported by a reader. See http://ludovicrousseau.blogspot.fr/2010/05/how-to-know-pin-sizes-supported-by.html

My CCID driver has some support of Gemalto readers.
See also http://ludovicrousseau.blogspot.fr/2014/02/new-version-of-libccid-1415.html

You may ask AET to improve their PKCS#11 library to use the mechanism I described in my blog.


>From uzi-in-xiring-class3:
Sep 26 14:42:33 portege pcscd: ifdhandler.c:1360:IFDHControl()
ControlCode: 0x42330006, usb:0f14/0011:libudev:0:/dev/bus/usb/002/013
(lun: 0)
Sep 26 14:42:33 portege pcscd: Control TxBuffer: 1E 1E 82 08 00 08 04
03 01 00 00 00 00 00 00 0D 00 00 00 00 20 00 82 08 00 00 00 00 00 00
00 00
Sep 26 14:42:40 portege pcscd: Control RxBuffer: 90 00 Secure verify PIN worked

>From test-in-xiring-class3:
Sep 26 15:15:59 portege pcscd: ifdhandler.c:1360:IFDHControl()
ControlCode: 0x42330006, usb:0f14/0011:libudev:0:/dev/bus/usb/002/026
(lun: 0)
Sep 26 15:15:59 portege pcscd: Control TxBuffer: 1E 1E 82 0F 00 0F 04
03 01 00 00 00 00 00 00 14 00 00 00 01 20 00 03 0F 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Sep 26 15:15:59 portege pcscd: Control RxBuffer: 6B 80

The reader (or card) returned 6B 80.
I could not find what 6B 80 is for 7816-4

Bye,

--
 Dr. Ludovic Rousseau

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PINPAD quirks

Dirk-Willem van Gulik
In reply to this post by J.Witvliet

Sounds reasonable enough if neither combinations worked.
But one smartcard (the UZI) _does_works in the Xiring-cl3 and also the omnikey_cl2 (so applet+library+reader CAN work)
And my MoD-card work in the omnikey-cl2 but not in the Xiring-cl3 (only one variable: the reader)
And that working card+library fails when trying another class-3 reader, the gemalto-cl3 (again only one variable: the reader)

I'm surely not part of the SafeSign-fan-club, but regarding above situations, makes me wonder if I have a case at AET…

Are you using the AET driver ? Do not just check te version - check the hash of their PKCS#11 binary - I’ve found undocumented quirks when
used with the dutch medical cards which seem to make assumptions about the PIN pad ability of the reader. 

Dw




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel