Hey, >> Companies who add C_* functions (nCipher, NetID ... others?) or use require the use of pReserved pointers (NSS) are not nice. Better call it CX_UnblockPIN instead of C_UnblockPIN. MIME is nice, with the x- prefix for non-standard subtypes. Ok i hear you.
>> You can do the same with "pkcs15-tool --unblock-pin -a <your main PIN>" as the shell, if you use OpenSC PKCS#11 for GDM login. Yes I was aware of this, however we never fully got this working in Fedora 10. Probably a misconfiguration from my part, never looked deeper into it though. >> Some thoughts for improvement: >> - use isdigit() to check the PIN code (but it should be safe to leave this for the module itself to validate) Understood. >> - use CKU_SO/CKU_USER for the usertype instead of numeric constants. Ok, cool will do that instead. >> - do a C_GetSlotList() call and use the first slot, not a numeric slot id of "1". While this probably works for the netID module (for which it is designed to work) if they decide to update their module to be more PKCS#11 v2.20 conforming, the slot ID might change. There's a difference in "slot with ID 1" and "slot with index 1 in the slot list": Ok, cool will do that instead. Thanks for the input Martin. Patrik Martinsson, Sweden. On 09/08/2010 11:48 AM, Martin Paljak wrote: > Hello, > On Sep 8, 2010, at 10:30 AM, Patrik Martinsson wrote: > >> I just wanted to share a small program I wrote for unlocking pin's with your >> puk. >> This will *only* work if you use NetID as provider, since they added the >> C_unlockPIN function to make this possible. >> > Companies who add C_* functions (nCipher, NetID ... others?) or use require > the use of pReserved pointers (NSS) are not nice. Better call it > CX_UnblockPIN instead of C_UnblockPIN. MIME is nice, with the x- prefix for > non-standard subtypes. > > >> So the thinking process around this is, >> 1. User locks his card, god knows why. (Who enters the pin wrong 5 times=)) >> 2. User calls the helpdesk, who tells the user to switch to a free console >> and login as the "unlock_pin"-user with some password. >> 3. Since the "unlock-pin"-user has this program as default shell, the user >> (who locked his card) will now be prompted with this program, and thus have >> the ability to unlock their card with the puk. >> > You can do the same with "pkcs15-tool --unblock-pin -a<your main PIN>" as > the shell, if you use OpenSC PKCS#11 for GDM login. > > > >> I would love to see this possibility (as i previously mentioned on the list) >> available in gdm (screensaver/login/whatever), however since there is no way >> of unlocking pins in pkcs11-standard (due to the security aspect, if i >> understood it correctly), I understand that this will not happen. However, >> we need a way of handling locked cards, therefore this program. >> > I would not say it is because of security reasons, it just happens to be so > that there is no simple function in PKCS#11 for PIN unblocking. The process > of unlocking PIN codes can involve other activities than a PUK verification. > It is often token specific. > > If you read between the lines from PCKS#15 or PKCS#11, initialization and > other "complex operations" and "product/vendor specific things" are many and > they are left outside the scope of these documents: > """ > The C_InitToken function may not be sufficient to properly initialize complex > tokens. In these situations, an initialization mechanism outside the scope of > Cryptoki must be employed. The definition of “complex token” is product > specific. > """ > > OpenSC can do PIN unblocking with some tricking: > > # User PIN unblock style > # none: PIN unblock is not possible with PKCS#11 API; > # set_pin_in_unlogged_session: C_SetPIN() in unlogged session: > # PUK is passed as the 'OldPin' argument of the C_SetPIN() call. > # set_pin_in_specific_context: C_SetPIN() in the CKU_SPECIFIC_CONTEXT > logged session: > # PUK is passed as the 'OldPin' argument of the C_SetPIN() call. > # init_pin_in_so_session: C_InitPIN() in CKU_SO logged session: > # User PIN 'UNBLOCK' is protected by SOPIN. (PUK == SOPIN). > # # Actually this style works only for the PKCS15 contents without > SOPIN. > # # For those with SOPIN, this mode will be usefull for the cards > without > # # modes 00 and 01 of ISO command 'RESET RETRY COUNTER'. --vt > # > # Default: none > # user_pin_unblock_style = set_pin_in_unlogged_session; > > > >> Anyway, for anyone that uses NetID as provider and needs this functionality, >> feel free to use it, and contact me if any question arise. >> Things to handle better is the possibility to have multiple readers, and >> usage of different slots. This program only use the first reader available >> and slot=1. >> > I thought that multiple readers looks no different from PKCS#11 perspective > than using multipel slots? Read below about slots. > > > >> Any comments, suggestions, improvements, thoughts around this method, are >> welcome. (Go easy on the coding-part since I'm not a programmer) >> > Some thoughts for improvement: > - use isdigit() to check the PIN code (but it should be safe to leave this > for the module itself to validate) > - use CKU_SO/CKU_USER for the usertype instead of numeric constants. > - do a C_GetSlotList() call and use the first slot, not a numeric slot id > of "1". While this probably works for the netID module (for which it is > designed to work) if they decide to update their module to be more PKCS#11 > v2.20 conforming, the slot ID might change. There's a difference in "slot > with ID 1" and "slot with index 1 in the slot list": > > """ > A list of CK_SLOT_IDs is returned by C_GetSlotList. A priori, any value of > CK_SLOT_ID can be a valid slot identifier—in particular, a system may have a > slot identified by the value 0. It need not have such a slot, however. > ... > All slots which C_GetSlotList reports must be able to be queried as valid > slots by C_GetSlotInfo. Furthermore, the set of slots accessible through a > Cryptoki library is checked at the time that C_GetSlotList, for list length > prediction (NULL pSlotList argument) is called. > """ > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
