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: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; opensc-devel@lists.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: [EMAIL PROTECTED]
> To: opensc-devel@lists.opensc-project.org
> Subject: Re: [opensc-devel] lock_login
>
> On Feb 1, 2008 1:48 PM, Franz Brandl <[EMAIL PROTECTED]> 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
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
Express yourself instantly with MSN Messenger! MSN Messenger
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
