honoring PINPAD

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

honoring PINPAD

J.Witvliet

Hi all,

 

Can anybody shine some light over this?

 

We finally have found some pinpad-readers that do work under Linux, with our cards and the AET-drivers.

For instance, if I type opensc-tool –l, I can see with readers have a pinpad or not

Also, when I do pkcs11-tool –O –l, I _must_ enter the pin on the reader.

Furthermore the screen-lock (driven by pam) knows when to ask for a pin, or refer to the reader-console.

However, openvpn simply continueus to ask for the pin on the console (or its management interface).

 

I presume openvpn should have checked the reader’s capabilities, but forgot to do that…

 

Secondly, as the code works with the pin on the prompt, I presume there is a switch (routine in libccid ??) that specifies IF a pinpad should be used or not?

So you can optionally overrule the pinpad-capability???

 

 

Kind regards, 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.

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: honoring PINPAD

Douglas E Engert


On 3/10/2016 9:23 AM, [hidden email] wrote:

> Hi all,
>
> Can anybody shine some light over this?
>
> We finally have found some pinpad-readers that do work under Linux, with our cards and the AET-drivers.
>
> For instance, if I type opensc-tool –l, I can see with readers have a pinpad or not
>
> Also, when I do pkcs11-tool –O –l, I _/must/_ enter the pin on the reader.
>
> Furthermore the screen-lock (driven by pam) knows when to ask for a pin, or refer to the reader-console.
>
> However, openvpn simply continueus to ask for the pin on the console (or its management interface).
>
> I presume openvpn should have checked the reader’s capabilities, but forgot to do that…

There is more work to do to use the pinpad reader. The code has to setup the template so the reader knows how to fill in the PIN.

>
> Secondly, as the code works with the pin on the prompt, I presume there is a switch (routine in libccid ??) that specifies IF a pinpad should be used or not?

I don't think so, it really enforced by the the calling software, OpenSC, openvpn or whatever....

 From a security standpoint, the card can not tell if the pin came from the pin pad reader or from the host.

There maybe readers that will not accept a pin command from the host. (I don't know of any.)
So if you are trying to force the user to never expose their pin to host (either on the keyboard or from a file) and always use the pin pad reader, you would need
one of these readers. You would also have to force the user not to change readers!

There may be issues trying to enforce this with Remote Desktop over the network.



>
> So you can optionally overrule the pinpad-capability???
>
> Kind regards, 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.
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: honoring PINPAD

Ludovic Rousseau


2016-03-10 17:53 GMT+01:00 Douglas E Engert <[hidden email]>:


On 3/10/2016 9:23 AM, [hidden email] wrote:
> Hi all,
>
> Can anybody shine some light over this?
>
> We finally have found some pinpad-readers that do work under Linux, with our cards and the AET-drivers.
>
> For instance, if I type opensc-tool –l, I can see with readers have a pinpad or not
>
> Also, when I do pkcs11-tool –O –l, I _/must/_ enter the pin on the reader.
>
> Furthermore the screen-lock (driven by pam) knows when to ask for a pin, or refer to the reader-console.
>
> However, openvpn simply continueus to ask for the pin on the console (or its management interface).
>
> I presume openvpn should have checked the reader’s capabilities, but forgot to do that…

There is more work to do to use the pinpad reader. The code has to setup the template so the reader knows how to fill in the PIN.

>
> Secondly, as the code works with the pin on the prompt, I presume there is a switch (routine in libccid ??) that specifies IF a pinpad should be used or not?

I don't think so, it really enforced by the the calling software, OpenSC, openvpn or whatever....

 From a security standpoint, the card can not tell if the pin came from the pin pad reader or from the host.

There maybe readers that will not accept a pin command from the host. (I don't know of any.)

Exact. At least Gemalto provides such pinpad readers.
The feature is called "firewall" and the reader will refuse any VERIFY (and similar) command with the PIN sent from the host. With this reader you can only verify a PIN using the pinpad keyboard.

You can have a look at some extra features available at https://pcsclite.alioth.debian.org/ccid/readers/extra_features/
For example https://pcsclite.alioth.debian.org/ccid/readers/extra_features/Gemalto_Ezio_Shield_PinPad_features.txt has:
Firewall: True
The same reader model can have the firewall feature enabled or not. I guess you will have to specify what configuration you want when buying the readers.

So if you are trying to force the user to never expose their pin to host (either on the keyboard or from a file) and always use the pin pad reader, you would need
one of these readers. You would also have to force the user not to change readers!

There may be issues trying to enforce this with Remote Desktop over the network.

The application can check the reader VendorID/ProductID to verify it is still the same reader. But you can't fight against the user if he is root on the system and can change any software and use another reader instead.
But I am not sure why the user would want to steal his own secret PIN.


> So you can optionally overrule the pinpad-capability???

There is no switch in libccid for force the use of the pinpad. It is only an application decision.
But the reader has such a switch.

Bye

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: honoring PINPAD

Frank Morgner
Use `enable_pinpad = false;` to disable the PIN-pad
https://github.com/OpenSC/OpenSC/blob/master/etc/opensc.conf.in#L96.
But have in mind the limitations already spoken about.

You should delegate the PIN-Pad problem to OpenVPN!



Am Donnerstag, dem 10. März, um 22:15 Uhr schrieb Ludovic Rousseau:

> 2016-03-10 17:53 GMT+01:00 Douglas E Engert <[hidden email]>:
>
> >
> >
> > On 3/10/2016 9:23 AM, [hidden email] wrote:
> > > Hi all,
> > >
> > > Can anybody shine some light over this?
> > >
> > > We finally have found some pinpad-readers that do work under Linux, with
> > our cards and the AET-drivers.
> > >
> > > For instance, if I type opensc-tool –l, I can see with readers have a
> > pinpad or not
> > >
> > > Also, when I do pkcs11-tool –O –l, I _/must/_ enter the pin on the
> > reader.
> > >
> > > Furthermore the screen-lock (driven by pam) knows when to ask for a pin,
> > or refer to the reader-console.
> > >
> > > However, openvpn simply continueus to ask for the pin on the console (or
> > its management interface).
> > >
> > > I presume openvpn should have checked the reader’s capabilities, but
> > forgot to do that…
> >
> > There is more work to do to use the pinpad reader. The code has to setup
> > the template so the reader knows how to fill in the PIN.
> >
> > >
> > > Secondly, as the code works with the pin on the prompt, I presume there
> > is a switch (routine in libccid ??) that specifies IF a pinpad should be
> > used or not?
> >
> > I don't think so, it really enforced by the the calling software, OpenSC,
> > openvpn or whatever....
> >
> >  From a security standpoint, the card can not tell if the pin came from
> > the pin pad reader or from the host.
> >
> > There maybe readers that will not accept a pin command from the host. (I
> > don't know of any.)
> >
>
> Exact. At least Gemalto provides such pinpad readers.
> The feature is called "firewall" and the reader will refuse any VERIFY (and
> similar) command with the PIN sent from the host. With this reader you can
> only verify a PIN using the pinpad keyboard.
>
> You can have a look at some extra features available at
> https://pcsclite.alioth.debian.org/ccid/readers/extra_features/
> For example
> https://pcsclite.alioth.debian.org/ccid/readers/extra_features/Gemalto_Ezio_Shield_PinPad_features.txt
> has:
>
> Firewall: True
>
> The same reader model can have the firewall feature enabled or not. I guess
> you will have to specify what configuration you want when buying the
> readers.
>
> So if you are trying to force the user to never expose their pin to host
> > (either on the keyboard or from a file) and always use the pin pad reader,
> > you would need
> > one of these readers. You would also have to force the user not to change
> > readers!
> >
> > There may be issues trying to enforce this with Remote Desktop over the
> > network.
> >
>
> The application can check the reader VendorID/ProductID to verify it is
> still the same reader. But you can't fight against the user if he is root
> on the system and can change any software and use another reader instead.
> But I am not sure why the user would want to steal his own secret PIN.
>
>
> > So you can optionally overrule the pinpad-capability???
> >
>
> There is no switch in libccid for force the use of the pinpad. It is only
> an application decision.
> But the reader has such a switch.
>
> Bye
>
> --
>  Dr. Ludovic Rousseau

> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel

--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: honoring PINPAD

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

Please find some comment/explenation below…

 

From: Ludovic Rousseau [mailto:[hidden email]]
Sent: donderdag 10 maart 2016 22:15
To: [hidden email]
Subject: Re: [Opensc-devel] honoring PINPAD

 

 

 

2016-03-10 17:53 GMT+01:00 Douglas E Engert <[hidden email]>:



On 3/10/2016 9:23 AM, [hidden email] wrote:
> Hi all,
>
> Can anybody shine some light over this?
>
> We finally have found some pinpad-readers that do work under Linux, with our cards and the AET-drivers.
>
> For instance, if I type opensc-tool –l, I can see with readers have a pinpad or not
>
> Also, when I do pkcs11-tool –O –l, I _/must/_ enter the pin on the reader.
>
> Furthermore the screen-lock (driven by pam) knows when to ask for a pin, or refer to the reader-console.
>
> However, openvpn simply continueus to ask for the pin on the console (or its management interface).
>
> I presume openvpn should have checked the reader’s capabilities, but forgot to do that…

There is more work to do to use the pinpad reader. The code has to setup the template so the reader knows how to fill in the PIN.

>
> Secondly, as the code works with the pin on the prompt, I presume there is a switch (routine in libccid ??) that specifies IF a pinpad should be used or not?

I don't think so, it really enforced by the the calling software, OpenSC, openvpn or whatever....

 From a security standpoint, the card can not tell if the pin came from the pin pad reader or from the host.

There maybe readers that will not accept a pin command from the host. (I don't know of any.)

 

Exact. At least Gemalto provides such pinpad readers.

The feature is called "firewall" and the reader will refuse any VERIFY (and similar) command with the PIN sent from the host. With this reader you can only verify a PIN using the pinpad keyboard.

 

You can have a look at some extra features available at https://pcsclite.alioth.debian.org/ccid/readers/extra_features/

For example https://pcsclite.alioth.debian.org/ccid/readers/extra_features/Gemalto_Ezio_Shield_PinPad_features.txt has:

Firewall: True

The same reader model can have the firewall feature enabled or not. I guess you will have to specify what configuration you want when buying the readers.

 

So if you are trying to force the user to never expose their pin to host (either on the keyboard or from a file) and always use the pin pad reader, you would need
one of these readers. You would also have to force the user not to change readers!

There may be issues trying to enforce this with Remote Desktop over the network.

 

The application can check the reader VendorID/ProductID to verify it is still the same reader. But you can't fight against the user if he is root on the system and can change any software and use another reader instead.

But I am not sure why the user would want to steal his own secret PIN.

 

 

> So you can optionally overrule the pinpad-capability???

 

There is no switch in libccid for force the use of the pinpad. It is only an application decision.

But the reader has such a switch.

Bye


--

 Dr. Ludovic Rousseau

 

 

Thanks Dr. Rousseau,

I’ve seen and used the info on your page before.

 

The complicating factor with respect to PINPAD readers however is our AET software (card-applet and driver on the pc), they are a further limiting factor.

I have several PP-readers that should work ok, and indeed, with the cards I bought and initialized myself (like myEID) they work correctly.

But our ministry supplied smartcard, just fails with most readers….

 

Since I’ve found two working PINPAD-readers, I was overjoyed!

So we do have readers that work, with some applications.

Point now is, that openvpn simply ignore the PP-functionality of the reader by default.

 

I fully agree that the card itself should not be aware or care, what kind of reader it is inserted into.

And I understand that it is up to the application itself, to detect the reader-capabilities, and act accordingly.

So the application can decide the ignore the extra capabilities, and treat it like a dumb class-1 reader,

Or the application has to fill-in templates for allowing the PINPAD-capabilities.

That sounds like an configuration-option for the appropriate application….

 

Thank you for education me (and perhaps others)

Kind regards, 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.

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel