Pierre Ossman: > On Wed, 2 Dec 2009 12:48:56 +0300 > "Aktiv Co. Aleksey Samsonov" <[email protected]> wrote: >> Pierre Ossman: >>> I've had another look at this and implemented a somewhat ugly hack to >>> provide this functionality. Basically C_Login will return success for >>> CKU_SO if it can't find an auth object and then rely on the PIN cache >>> in C_InitPIN. >>> >>> Comment away! >> Please see: >> http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012894.html >> http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012891.html >> > > I see. Does anyone have any comments on the general principle though > before I start putting time into updating to trunk?
> + /* This assumes that either: > + * (a) We have a cached SO PIN > + * (b) We have previously logged in as CKU_SO and the card > + * will therefore accept the unblock request. */ > + rc = sc_pkcs15_unblock_pin(fw_data->p15_card, pin, > + slot_data->pin[CKU_SO].value, > + slot_data->pin[CKU_SO].len, > + pPin, ulPinLen); What are the cards support it? (sc_pkcs15_unblock_pin with "puk" is CKU_SO and "newpin" is pPin) How many of them from the total number working in OpenSC? Alternative sheme: Reimplement "reset_retry_counter" or "pin_cmd -> SC_PIN_CMD_UNBLOCK" that it no use "puk" and "newpin", it merely send apdu with ref_unblock_pin. At that time C_Login(..., CKU_SO, ...); C_InitPIN(..., "", 0) -> sc_pkcs15_unblock_pin(..., NULL, 0, "", 0); But, I don't like misuse of C_InitPIN concept. _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
