PIN readers and OpenSC.tokend

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

PIN readers and OpenSC.tokend

Dirk-Willem van Gulik
We currently do not handle the situation of a reader with a PIN pad quite correct in OpenSC.tokend. Which is a bit painful in medical settings; where this is now becoming really rather common. And as one gets no feedback; it is easy for the user to block the card with 3 attempts by simply inserting it while the keychain app is running.

Unfortunately the OS passes us a “\0” and len = 0 rather than a NULL and 0 from the prompt; so pkcs15-pin.c its:

     if(p15card->card->reader->capabilities & SC_READER_CAP_PIN_PAD) {
                if (!pincode && !pinlen) {
                        data.flags |= SC_PIN_CMD_USE_PINPAD;

is not triggered. And I cannot think of anything in getAcl in terms of things like  AclFactory:: announcements to make that happen either. On absence or prompted verify is simply not called.

Now we could change above into p

                if ((!pincode || *pincode == ‘\0’)&& !pinlen) {
or even
                if (!pincode || !pinlen) {
                        pincode = NULL; pinlen = 0;
                        ...

as really that would mean no valid pin anyway. Does that break anything ? Now we could also do this at the OpenSCToken.cpp level — see the patch below. At least we know more about the semantics of pin and pinlength. Or we could trap this as a special case - knowing it comes in without a verify; track the (lack of) verify; and do a verify(NULL,0) in all other calls to catch it.

Any suggestions ? In an ideal case the prompt on the screen would not even show; with below one can at least type an empty value.

Dw.


diff --git a/OpenSC/OpenSCToken.cpp b/OpenSC/OpenSCToken.cpp
index 2cc46c5..13aeca6 100644
--- a/OpenSC/OpenSCToken.cpp
+++ b/OpenSC/OpenSCToken.cpp
@@ -173,6 +173,14 @@ bool OpenSCToken::_verifyPIN(int pinNum, const uint8_t *pin, size_t pinLength)
 
        int r, i, rv;
        struct sc_pkcs15_object *objs[32];

+    if (mScP15Card->card->reader->capabilities & SC_READER_CAP_PIN_PAD) {
+        sc_debug(mScCtx, SC_LOG_DEBUG_NORMAL, pinLength ? “Ignore the PinPad against policy” : "Defer to the PIN pad.”);
+        if (!pinLength)
+            pin = NULL;
+    }

        // pinNum -> AuthID
        const sc_pkcs15_id_t *auth_id = getIdFromPinMap(pinNum);


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN readers and OpenSC.tokend

Ludovic Rousseau
Hello,

2015-03-31 16:57 GMT+02:00 Dirk-Willem van Gulik <[hidden email]>:

> We currently do not handle the situation of a reader with a PIN pad quite correct in OpenSC.tokend. Which is a bit painful in medical settings; where this is now becoming really rather common. And as one gets no feedback; it is easy for the user to block the card with 3 attempts by simply inserting it while the keychain app is running.
>
> Unfortunately the OS passes us a “\0” and len = 0 rather than a NULL and 0 from the prompt; so pkcs15-pin.c its:
>
>      if(p15card->card->reader->capabilities & SC_READER_CAP_PIN_PAD) {
>                 if (!pincode && !pinlen) {
>                         data.flags |= SC_PIN_CMD_USE_PINPAD;
>
> is not triggered. And I cannot think of anything in getAcl in terms of things like  AclFactory:: announcements to make that happen either. On absence or prompted verify is simply not called.
>
> Now we could change above into p
>
>                 if ((!pincode || *pincode == ‘\0’)&& !pinlen) {
> or even
>                 if (!pincode || !pinlen) {
>                         pincode = NULL; pinlen = 0;
>                         ...
>
> as really that would mean no valid pin anyway. Does that break anything ? Now we could also do this at the OpenSCToken.cpp level — see the patch below. At least we know more about the semantics of pin and pinlength. Or we could trap this as a special case - knowing it comes in without a verify; track the (lack of) verify; and do a verify(NULL,0) in all other calls to catch it.
>
> Any suggestions ? In an ideal case the prompt on the screen would not even show; with below one can at least type an empty value.

I prefer to have the modification in the tokend. It is an Apple
bug/limitation so that should be fixed/circumvented in a Mac OS X
layer.

> diff --git a/OpenSC/OpenSCToken.cpp b/OpenSC/OpenSCToken.cpp
> index 2cc46c5..13aeca6 100644
> --- a/OpenSC/OpenSCToken.cpp
> +++ b/OpenSC/OpenSCToken.cpp
> @@ -173,6 +173,14 @@ bool OpenSCToken::_verifyPIN(int pinNum, const uint8_t *pin, size_t pinLength)
>
>         int r, i, rv;
>         struct sc_pkcs15_object *objs[32];
>
> +    if (mScP15Card->card->reader->capabilities & SC_READER_CAP_PIN_PAD) {
> +        sc_debug(mScCtx, SC_LOG_DEBUG_NORMAL, pinLength ? “Ignore the PinPad against policy” : "Defer to the PIN pad.”);
> +        if (!pinLength)
> +            pin = NULL;
> +    }
>
>         // pinNum -> AuthID
>         const sc_pkcs15_id_t *auth_id = getIdFromPinMap(pinNum);

Maybe make the log messages more explicit?
Otherwise it is OK for me.

Bye

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN readers and OpenSC.tokend

Dirk-Willem van Gulik

On 31 Mar 2015, at 18:17, Ludovic Rousseau <[hidden email]> wrote:

2015-03-31 16:57 GMT+02:00 Dirk-Willem van Gulik <[hidden email]>:
We currently do not handle the situation of a reader with a PIN pad quite correct in OpenSC.tokend. Which is a bit painful in medical settings; where this is now becoming really rather common. And as one gets no feedback; it is easy for the user to block the card with 3 attempts by simply inserting it while the keychain app is running.
….

I prefer to have the modification in the tokend. It is an Apple
bug/limitation so that should be fixed/circumvented in a Mac OS X
layer.

Maybe make the log messages more explicit?
Otherwise it is OK for me.

Updated and a patch/diff at:
Dw.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel