Pierre Ossman wrote:
On Thu, 03 Dec 2009 16:57:55 +0100
Viktor TARASOV <viktor.tara...@opentrust.com> wrote:
In fact, reading the pkcs11.v2.20 pp 116:
C_SetPIN modifies the PIN of the user that is currently logged in, or
the CKU_USER PIN if the session is not logged in.
So, C_Login(CKU_SO) + C_InitPIN() is not the only PIN unblocking scheme.
But C_SetPIN requires knowledge of the existing PIN, which the user
most likely doesn't have if they've managed to lock themselves out.
And even if they know the correct PIN, how would OpenSC go about
verifying this since the card will refuse to validate the PIN now that
it is locked?
I understood this phrase in the following way:
-- if C_SetPIN() is preceded by C_Login(CKU_XX), then C_SetPIN will
change the XX PIN.
In this case the 'pOldPin' argument is the current PIN value
or empty (if P1=01 mode of the ISO 'Change Reference Data' command is
used
or PIN is already cached during the C_Login());
-- if C_SetPIN() is not preceded by C_Login then it's implicitly the
User PIN is going to be changed.
In this case the 'pOldPin' argument is the unblocking code.
For me it's quite logical, because, as you've told,
we do not have or cannot use the actual PIN value.
The standard uses term 'modify' - for me it can be the both - 'change'
and 'unlock'.
To make 'PIN change' there is the C_Login()+C_SetPIN() mode.
So, the other mode is for 'PIN unlock', and, IMHO, this mode fits quite
well to 'PIN unlock'.
Rgds
Kind wishes,
--
Viktor Tarasov <viktor.tara...@opentrust.com>
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
