Re: lock_login

Hi,

please let me again come back on my lock_login problem with A-Trust ACOS cards. I have checked in the sources, and this are the details. I hope that someone can help me out

The problem occurs during signatures (for example triggered by "pkcs11-tool -t") in pkcs15_prkey_sign (framework-pkcs15.c). The code is

    if (!sc_pkcs11_conf.lock_login) {
        rv = reselect_app_df(fw_data->p15_card);

When lock_login is False, the DF is selected which destroys the PIN state of the card. Later on, the signature command fails (security status not satisfied).

The driver specific select_file function has no easy way to determine the situation because the card->cache.current_path has been emptied previously by the unlock method.

Any hints on how to solve this (other than setting lock_login to True) ?

Maybe this behaviour is in fact somehow logically; if one decides to free up card access, to enable other apps access, one might not want to release the card to other apps with the PIN presented. This might be circumvented by using a PIN cache, but since here in Austria, PIN pad readers are quite common, a PIN cache cannot be a common solution.

Thanks in advance,
Franz

---

From: ez2517hotmail.com
To: ludovic.rousseaugmail.com; opensc-devellists.opensc-project.org
Date: Sun, 3 Feb 2008 20:39:26 +0000
Subject: Re: [opensc-devel] lock_login

Hello,

it shouldn't be an application problem, i guess it is rather a problem in the A-Trust ACOS specific code, but i wasnt able to figure out a "quick fix".

The problem occurs even with "pkcs11-tool /t /l xxxx", when testing the signatures.

The problem is that during that test, the card is repeatedly locked/unlocked, and on unlock, the cache that holds the selected path is destroyed.

Furthermore, during the signature tests (and during an open PKCS#11 session), a function is called that "re-selects" the SC application/path. This is done only when lock_login is not set (!). This re-selection of the application/path destroys the PIN state of the card cause the card uses local PINs, and their state is reset on SELECT DF, even if the current DF is selected again.
This causes the subsequent SC command that actually calculates the signature to fail.
Sorry for the not-to-specific info, i'm not in the office now, but i can give the exact names of the functions that i am talking about on tuesday.

I guess that to fix this issue, i would need some static information about the selected DF in the card specific code that survives the "unlock" - but i am not sure that is a good idea, cause i guess that in the card specific code, i cannot be sure that there has not been another access or a reset to the card which also changed the PIN state.

Maybe i am completely overlooking something here (is there a different way to fix such an issue ?).

Thanks a lot,
Franz

---

> Date: Fri, 1 Feb 2008 15:37:25 +0100
> From: ludovic.rousseaugmail.com
> To: opensc-devellists.opensc-project.org
> Subject: Re: [opensc-devel] lock_login
>
> On Feb 1, 2008 1:48 PM, Franz Brandl <ez2517hotmail.com> wrote:
>; > Hi all,
>
> Hello,
>;
> > when testing a new generation of A-Trust ACOS based cards, i came across the
> > fact that the cards do not work with OpenSC when the lock_login parameter is
> > set to False.
>;
> What is the problem exactly with lock_login set to false?
>; Why does it not work with A-Trust ACOS based cards?
>;
> This flag should not be card specific. I guess a problem in your application.
>
> Bye
>
> --
> Dr. Ludovic Rousseau
&gt; _______________________________________________
> opensc-devel mailing list
> opensc-devellists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

---

Express yourself instantly with MSN Messenger! MSN Messenger