Re: [opensc-devel] Unblocking PIN via PKCS#11?
On 04.01.2010, at 12:33, Viktor TARASOV wrote: > Martin Paljak wrote: >> Hi. >> There seem to be two targets: >> a) How to accomplish all functionality via PKCS#11 interface >> b) How to remain compatible with as many as possible / select existing >> application implementations. ... > I propose to implement both scenarios and to parametrize their activating > from 'opensc-pkcs11' > section of opensc.conf . > This way, probably, we'll get some return from the actuals OpenSC users about > the preferable one. IMO that's the perfect solution. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Martin Paljak wrote: Hi. There seem to be two targets: a) How to accomplish all functionality via PKCS#11 interface b) How to remain compatible with as many as possible / select existing application implementations. IMHO, Exploiting C_Login(CKU_CONTEXT_SPECIFIC) + SetPIN() to achieve target a seems reasonably valid, as it does not seem to contradict the 2.20 spec. Achieving b will be probably anyway difficult, as there are different cards and different applications, which most probably have quirks themselves as well or work in a specific combination only. Is there a real life test-case or usage scenario (some "respectable" and common application used in the wild)? To me, C_SetPIN without a logged in user seems somewhat OK solution, even though I agree with the possible PUK counter decrease problem. Thus implementing the context specific trick for target a is OK, achieving target b requires a real life application example and investigation, what other implementations do (also to notice that proprietary pkcs#11 interfaces are usually tuned to the the specific hardware they support and thus probably can't be copied 1:1 into OpensC) I propose to implement both scenarios and to parametrize their activating from 'opensc-pkcs11' section of opensc.conf . This way, probably, we'll get some return from the actuals OpenSC users about the preferable one. Martin. On 04.01.2010, at 11:03, Pierre Ossman wrote: On Thu, 03 Dec 2009 14:57:34 +0100 Viktor TARASOV wrote: Another possible, 'alternative to alternative' scheme is to use C_SetPin() in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. Afais, CKU_CONTEXT_SPECIFIC is not actually used. The problem here is that this is not something that's specified in the standard, and it's not the system existing implementations use. I think that as far as the interface goes, C_Login(CKU_SO) followed by C_InitPin() is set in stone as we want to be compatible with what's already out there. On Fri, 04 Dec 2009 09:44:36 +0100 Viktor TARASOV wrote: -- 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. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Hi. There seem to be two targets: a) How to accomplish all functionality via PKCS#11 interface b) How to remain compatible with as many as possible / select existing application implementations. IMHO, Exploiting C_Login(CKU_CONTEXT_SPECIFIC) + SetPIN() to achieve target a seems reasonably valid, as it does not seem to contradict the 2.20 spec. Achieving b will be probably anyway difficult, as there are different cards and different applications, which most probably have quirks themselves as well or work in a specific combination only. Is there a real life test-case or usage scenario (some "respectable" and common application used in the wild)? To me, C_SetPIN without a logged in user seems somewhat OK solution, even though I agree with the possible PUK counter decrease problem. Thus implementing the context specific trick for target a is OK, achieving target b requires a real life application example and investigation, what other implementations do (also to notice that proprietary pkcs#11 interfaces are usually tuned to the the specific hardware they support and thus probably can't be copied 1:1 into OpensC) Martin. On 04.01.2010, at 11:03, Pierre Ossman wrote: > >> On Thu, 03 Dec 2009 14:57:34 +0100 >> Viktor TARASOV wrote: >> >>> >>> Another possible, 'alternative to alternative' scheme is to use C_SetPin() >>> in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). >>> >>> So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, >>> in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. >>> >>> Afais, CKU_CONTEXT_SPECIFIC is not actually used. >>> >> >> The problem here is that this is not something that's specified in the >> standard, and it's not the system existing implementations use. >> >> I think that as far as the interface goes, C_Login(CKU_SO) followed by >> C_InitPin() is set in stone as we want to be compatible with what's >> already out there. On Fri, 04 Dec 2009 09:44:36 +0100 Viktor TARASOV wrote: > -- 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. > -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
2010/1/4 Pierre Ossman : > Ludovic, you're listed as the author of unblock.py in pykcs11. Could > you give some input on this discussion? I am not a PKCS#11 expert. I am not sure C_SetPIN() can be used with a PUK to unlock a PIN. The PKCS#11 spec defines pOldPin as "pOldPin points to the old PIN". Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Ludovic, you're listed as the author of unblock.py in pykcs11. Could you give some input on this discussion? On Thu, 3 Dec 2009 15:09:26 +0100 Pierre Ossman wrote: > On Thu, 03 Dec 2009 14:57:34 +0100 > Viktor TARASOV wrote: > > > > > Another possible, 'alternative to alternative' scheme is to use C_SetPin() > > in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). > > > > So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, > > in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. > > > > Afais, CKU_CONTEXT_SPECIFIC is not actually used. > > > > The problem here is that this is not something that's specified in the > standard, and it's not the system existing implementations use. > > I think that as far as the interface goes, C_Login(CKU_SO) followed by > C_InitPin() is set in stone as we want to be compatible with what's > already out there. > > Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Fri, 04 Dec 2009 09:44:36 +0100 Viktor TARASOV wrote: > -- 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. > Only in this case. It's perfectly possible under another scenario that the user knows the PIN and only wishes to change it to a new one. I haven't done any research on existing implementations, but given the wording of the PKCS#11 spec, what you're suggesting sounds to me like it would break things. And to make things worse, it would probably have a high risk of expending the PUK attempts (as the user would be feeding it the PIN instead) and really screw the user over. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Viktor TARASOV wrote: From my point of view, the most 'standard' manner to do User 'PIN unblock' is with the C_SetPIN() in the unlogged session. If there are no objections against 'User PIN Unblock' with the 'C_SetPIN() in Unlogged Session', I'll commit it. Kind wishes, Viktor Tarasov. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman wrote: On Thu, 03 Dec 2009 16:32:01 +0100 Viktor TARASOV wrote: As for me, for the cards (rather 'pkcs15 contents') that do not have SOPIN or the only useful SOPIN function is 'unblock_user_pin' it's acceptable to use PUK as SOPIN and to use 'sc_pkcs15_unblock_pin' in C_InitPIN() . Could you elaborate on what other SO PINs there are out there According to standard the SO-PIN is not PUK - the role of SO is to initialize token and create User PIN . So, it's natural that our colleagues can oppose the idea to consider PUK==SOPIN . (As I've told above, it's not my case. ) There is no "PUK" notion in the standard. From my point of view, the most 'standard' manner to do User 'PIN unblock' is with the C_SetPIN() in the unlogged session. how my patch would cause problems in those cases. I need to look it more closely. All the cards I have experience with only have the PIN and PUK. There are the cases when at the card level SOPIN != PUK . Another question if this difference is exported by the driver to the upper level. Rgds Kind wishes, -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman wrote: On Thu, 03 Dec 2009 16:57:55 +0100 Viktor TARASOV 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Thu, 03 Dec 2009 16:32:01 +0100 Viktor TARASOV wrote: > > As for me, for the cards (rather 'pkcs15 contents') that do not have > SOPIN or the only useful SOPIN function is 'unblock_user_pin' it's > acceptable to use PUK as SOPIN and to use 'sc_pkcs15_unblock_pin' in > C_InitPIN() . > Could you elaborate on what other SO PINs there are out there and how my patch would cause problems in those cases. All the cards I have experience with only have the PIN and PUK. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Thu, 03 Dec 2009 16:57:55 +0100 Viktor TARASOV 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? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Aktiv Co. Aleksey Samsonov wrote: > Viktor TARASOV: >>> - in CKU_SO_PIN context -- set PIN after SOPIN authentication; >>> >> Sorry, it's not good idea -- there should be possibility to change >> SOPIN. > > Incidentally, this isn't work for current trunk. (change SOPIN by > C_SetPin) (see slot_data_auth/slot_data_pin_info and > http://www.opensc-project.org/opensc/browser/trunk/src/pkcs11/framework-pkcs15.c?rev=3868#L852) > > > In fact, thanks. 'In pricipe' SOPIN can be accessed in the CKU_SO_PIN context, for example with the C_SetPIN(). The standard says that C_SetPIN modifies the PIN of the current user. But actually, in pkcs15_change_pin() the logged user type is not checked. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman wrote: > On Thu, 03 Dec 2009 14:57:34 +0100 > Viktor TARASOV wrote: > > >> Another possible, 'alternative to alternative' scheme is to use C_SetPin() >> in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). >> >> So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, >> in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. >> >> Afais, CKU_CONTEXT_SPECIFIC is not actually used. >> >> > > The problem here is that this is not something that's specified in the > standard, and it's not the system existing implementations use. > > I think that as far as the interface goes, C_Login(CKU_SO) followed by > C_InitPin() is set in stone as we want to be compatible with what's > already out there. > 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. > Rgds > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman wrote: > On Thu, 03 Dec 2009 14:57:34 +0100 > Viktor TARASOV wrote: > > >> Another possible, 'alternative to alternative' scheme is to use C_SetPin() >> in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). >> >> So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, >> in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. >> >> Afais, CKU_CONTEXT_SPECIFIC is not actually used. >> >> > > The problem here is that this is not something that's specified in the > standard, and it's not the system existing implementations use. > > I think that as far as the interface goes, C_Login(CKU_SO) followed by > C_InitPin() is set in stone as we want to be compatible with what's > already out there. > That's right. Any way, with the existing standard we cannot cover all the variations of the PKCS15 contents and different card specifications. As for me, for the cards (rather 'pkcs15 contents') that do not have SOPIN or the only useful SOPIN function is 'unblock_user_pin' it's acceptable to use PUK as SOPIN and to use 'sc_pkcs15_unblock_pin' in C_InitPIN() . I'm not talking about the other possible situations with SOPIN!=PUK, number of PUKs, ... I guess that some option (use-puk-as-sopin) can be introduced into the 'pkcs11' section of opensc.conf. > Rgds > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Viktor TARASOV: >> - in CKU_SO_PIN context -- set PIN after SOPIN authentication; >> > Sorry, it's not good idea -- there should be possibility to change SOPIN. Incidentally, this isn't work for current trunk. (change SOPIN by C_SetPin) (see slot_data_auth/slot_data_pin_info and http://www.opensc-project.org/opensc/browser/trunk/src/pkcs11/framework-pkcs15.c?rev=3868#L852) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Viktor TARASOV wrote: > Viktor TARASOV wrote: > >> Aktiv Co. Aleksey Samsonov wrote: >> >> >>> Pierre Ossman: >>> >>> >>> I think we might have a language barrier here as I'm not quite following what you're trying to say. >>> Sorry for inconvenience caused. >>> >>> >>> >>> The basic problem is that none of my PKCS#15 cards have an object for the PUK (and from what I can tell the PKCS#15 standard doesn't require them to). This means that we cannot do a C_Login with the PUK beforehand (as we cannot figure out the reference of the PUK for the VERIFY operation). >>> Then "alternative sheme" isn't correct in this case. But, I fear for >>> call sc_pkcs15_unblock_pin if we have a cached SO PIN (if SO PIN != PUK). >>> >>> >>> >> Another possible, 'alternative to alternative' scheme is to use C_SetPin() >> in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). >> >> So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, >> in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. >> >> Afais, CKU_CONTEXT_SPECIFIC is not actually used. >> >> > Even better, > for C_SetPIN(): > - in CKU_USER_PIN context -- change PIN; > > - in CKU_SO_PIN context -- set PIN after SOPIN authentication; > Sorry, it's not good idea -- there should be possibility to change SOPIN. > - in CKU_SPECIFIC context -- 'one_step_unblock_PIN' or unblock PIN after > PUK (when PUK != SOPIN) authentication; > > >> >> >>> ___ >>> opensc-devel mailing list >>> opensc-devel@lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >>> >>> >>> >> >> > > > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Viktor TARASOV: > Another possible, 'alternative to alternative' scheme is to use C_SetPin() > in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). > > So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, > in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. > > Afais, CKU_CONTEXT_SPECIFIC is not actually used. I think, this is a very good idea. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Thu, 03 Dec 2009 14:57:34 +0100 Viktor TARASOV wrote: > > Another possible, 'alternative to alternative' scheme is to use C_SetPin() > in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). > > So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, > in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. > > Afais, CKU_CONTEXT_SPECIFIC is not actually used. > The problem here is that this is not something that's specified in the standard, and it's not the system existing implementations use. I think that as far as the interface goes, C_Login(CKU_SO) followed by C_InitPin() is set in stone as we want to be compatible with what's already out there. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Viktor TARASOV wrote: > Aktiv Co. Aleksey Samsonov wrote: > >> Pierre Ossman: >> >> >>> I think we might have a language barrier here as I'm not quite >>> following what you're trying to say. >>> >>> >> Sorry for inconvenience caused. >> >> >> >>> The basic problem is that none of my PKCS#15 cards have an object for >>> the PUK (and from what I can tell the PKCS#15 standard doesn't require >>> them to). This means that we cannot do a C_Login with the PUK >>> beforehand (as we cannot figure out the reference of the PUK for the >>> VERIFY operation). >>> >>> >> Then "alternative sheme" isn't correct in this case. But, I fear for >> call sc_pkcs15_unblock_pin if we have a cached SO PIN (if SO PIN != PUK). >> >> > > Another possible, 'alternative to alternative' scheme is to use C_SetPin() > in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). > > So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, > in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. > > Afais, CKU_CONTEXT_SPECIFIC is not actually used. > Even better, for C_SetPIN(): - in CKU_USER_PIN context -- change PIN; - in CKU_SO_PIN context -- set PIN after SOPIN authentication; - in CKU_SPECIFIC context -- 'one_step_unblock_PIN' or unblock PIN after PUK (when PUK != SOPIN) authentication; > >> ___ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel >> >> >> > > > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Aktiv Co. Aleksey Samsonov wrote: > Pierre Ossman: > >> I think we might have a language barrier here as I'm not quite >> following what you're trying to say. >> > > Sorry for inconvenience caused. > > >> The basic problem is that none of my PKCS#15 cards have an object for >> the PUK (and from what I can tell the PKCS#15 standard doesn't require >> them to). This means that we cannot do a C_Login with the PUK >> beforehand (as we cannot figure out the reference of the PUK for the >> VERIFY operation). >> > > Then "alternative sheme" isn't correct in this case. But, I fear for > call sc_pkcs15_unblock_pin if we have a cached SO PIN (if SO PIN != PUK). > Another possible, 'alternative to alternative' scheme is to use C_SetPin() in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. Afais, CKU_CONTEXT_SPECIFIC is not actually used. > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Thu, 3 Dec 2009 16:29:23 +0300 "Aktiv Co. Aleksey Samsonov" wrote: > > The basic problem is that none of my PKCS#15 cards have an object for > > the PUK (and from what I can tell the PKCS#15 standard doesn't require > > them to). This means that we cannot do a C_Login with the PUK > > beforehand (as we cannot figure out the reference of the PUK for the > > VERIFY operation). > > Then "alternative sheme" isn't correct in this case. But, I fear for > call sc_pkcs15_unblock_pin if we have a cached SO PIN (if SO PIN != PUK). > Can that happen when using the API correctly though? PKCS#11 only has two types of PIN, so SO PIN must be the PUK. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman: > I think we might have a language barrier here as I'm not quite > following what you're trying to say. Sorry for inconvenience caused. > The basic problem is that none of my PKCS#15 cards have an object for > the PUK (and from what I can tell the PKCS#15 standard doesn't require > them to). This means that we cannot do a C_Login with the PUK > beforehand (as we cannot figure out the reference of the PUK for the > VERIFY operation). Then "alternative sheme" isn't correct in this case. But, I fear for call sc_pkcs15_unblock_pin if we have a cached SO PIN (if SO PIN != PUK). ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Thu, 3 Dec 2009 13:38:43 +0300 "Aktiv Co. Aleksey Samsonov" wrote: > > 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. I think we might have a language barrier here as I'm not quite following what you're trying to say. The basic problem is that none of my PKCS#15 cards have an object for the PUK (and from what I can tell the PKCS#15 standard doesn't require them to). This means that we cannot do a C_Login with the PUK beforehand (as we cannot figure out the reference of the PUK for the VERIFY operation). My patch hacks around this limitation by caching the PUK and sending it with the RESET RETRY COUNTER operation, where the reference number of the PUK isn't needed. As for which cards will support this, it should be the same set as those "pkcs15-tool --unblock-pin" supports as it should work in the same way. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman: > On Wed, 2 Dec 2009 12:48:56 +0300 > "Aktiv Co. Aleksey Samsonov" 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 opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Wed, 2 Dec 2009 16:05:13 +0300 "Aktiv Co. Aleksey Samsonov" wrote: > Pierre Ossman: > > On Wed, 2 Dec 2009 12:48:56 +0300 > > "Aktiv Co. Aleksey Samsonov" wrote: > >> Pierre Ossman: > >>> 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? > > What are your going to do with cache_pin and pkcs15_slot_data::pin ? I didn't check what the new changes entailed, so I can't answer what changes I'll have to do. I assume there is still some PIN cache functionality in place? -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman: > On Wed, 2 Dec 2009 12:48:56 +0300 > "Aktiv Co. Aleksey Samsonov" wrote: >> Pierre Ossman: >>> 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? What are your going to do with cache_pin and pkcs15_slot_data::pin ? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Wed, 2 Dec 2009 12:48:56 +0300 "Aktiv Co. Aleksey Samsonov" 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? > > > --- src/pkcs11/framework-pkcs15.c (revision 18564) > The revisions are from our internal repo, so you should just ignore those in my diffs. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
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 > --- src/pkcs11/framework-pkcs15.c(revision 18564) For current trunk: In file included from framework-pkcs15.c:23: framework-pkcs15.c: In function 'pkcs15_login': framework-pkcs15.c:973: warning: implicit declaration of function 'cache_pin' framework-pkcs15.c: In function 'pkcs15_init_pin': framework-pkcs15.c:1144: error: 'struct pkcs15_slot_data' has no member named 'pin' framework-pkcs15.c:1145: error: 'struct pkcs15_slot_data' has no member named 'pin' make[3]: *** [framework-pkcs15.lo] Error 1 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Wed, 2 Dec 2009 09:51:20 +0100 Pierre Ossman wrote: > On Tue, 10 Nov 2009 18:48:21 +0100 > Pierre Ossman wrote: > > > I'm looking at implementing support for unblocking a locked PIN in my > > application, but looking at OpenSC that doesn't seem to be possible. In > > fact, there are a number of issues along the way. > > > > 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. > I should also add that this basically reverts a part of r1219 which seems to have been a mistake. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
On Tue, 10 Nov 2009 18:48:21 +0100
Pierre Ossman wrote:
> I'm looking at implementing support for unblocking a locked PIN in my
> application, but looking at OpenSC that doesn't seem to be possible. In
> fact, there are a number of issues along the way.
>
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!
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
Index: src/pkcs11/framework-pkcs15.c
===
--- src/pkcs11/framework-pkcs15.c (revision 18564)
+++ src/pkcs11/framework-pkcs15.c (working copy)
@@ -907,13 +907,18 @@
/* A card with no SO PIN is treated as if no SO login
* is required */
rc = sc_pkcs15_find_so_pin(card, &auth_object);
-
- /* If there's no SO PIN on the card, silently
- * accept any PIN, and lock the card if required */
- if (rc == SC_ERROR_OBJECT_NOT_FOUND
- && sc_pkcs11_conf.lock_login)
+ if (rc == SC_ERROR_OBJECT_NOT_FOUND) {
+ /* Need to lock the card though */
rc = lock_card(fw_data);
- if (rc < 0)
+ if (rc < 0) {
+ return sc_to_cryptoki_error(rc,
+ p11card->reader);
+ }
+ /* And cache the PIN as init_pin might need it */
+ cache_pin(fw_token, userType, NULL, pPin, ulPinLen);
+ return CKR_OK;
+ }
+ else if (rc < 0)
return sc_to_cryptoki_error(rc, p11card->reader);
break;
default:
@@ -1006,11 +1011,11 @@
return sc_to_cryptoki_error(rc, p11card->reader);
}
-#ifdef USE_PKCS15_INIT
-static CK_RV pkcs15_init_pin(struct sc_pkcs11_card *p11card,
+static CK_RV pkcs15_create_pin(struct sc_pkcs11_card *p11card,
struct sc_pkcs11_slot *slot,
CK_CHAR_PTR pPin, CK_ULONG ulPinLen)
{
+#ifdef USE_PKCS15_INIT
struct pkcs15_fw_data *fw_data = (struct pkcs15_fw_data *) p11card->fw_data;
struct sc_pkcs15init_pinargs args;
struct sc_profile *profile;
@@ -1052,8 +1057,52 @@
cache_pin(slot->fw_data, CKU_USER, &pin_info->path, pPin, ulPinLen);
return CKR_OK;
+#else
+ return CKR_FUNCTION_NOT_SUPPORTED;
+#endif
}
+static CK_RV pkcs15_init_pin(struct sc_pkcs11_card *p11card,
+ struct sc_pkcs11_slot *slot,
+ CK_CHAR_PTR pPin, CK_ULONG ulPinLen)
+{
+ struct pkcs15_fw_data *fw_data;
+ struct pkcs15_slot_data *slot_data;
+ struct sc_pkcs15_pin_info *pin;
+ int rc;
+
+ fw_data = (struct pkcs15_fw_data *)p11card->fw_data;
+ slot_data = (struct pkcs15_slot_data *)slot->fw_data;
+
+ pin = slot_data_pin_info(slot_data);
+
+ /* If we don't have a PIN then we want to create it */
+ if (!pin) {
+ sc_debug(context, "No PIN found. Attempting to create one...\n");
+ return pkcs15_create_pin(p11card, slot, pPin, ulPinLen);
+ }
+
+ /* Otherwise we want to reset the one we have */
+
+ if (ulPinLen < pin->min_length ||
+ ulPinLen > pin->max_length)
+ return CKR_PIN_LEN_RANGE;
+
+ /* 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);
+ if (rc < 0)
+ return sc_to_cryptoki_error(rc, p11card->reader);
+
+ return CKR_OK;
+}
+
+#ifdef USE_PKCS15_INIT
static CK_RV pkcs15_create_private_key(struct sc_pkcs11_card *p11card,
struct sc_pkcs11_slot *slot,
struct sc_profile *profile,
@@ -1690,14 +1739,13 @@
pkcs15_logout,
pkcs15_change_pin,
NULL, /* init_token */
+ pkcs15_init_pin,
#ifdef USE_PKCS15_INIT
- pkcs15_init_pin,
pkcs15_create_object,
pkcs15_gen_keypair,
#else
NULL,
NULL,
- NULL,
#endif
NULL, /* seed_random */
pkcs15_get_random
signature.asc
Description: PGP signature
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Unblocking PIN via PKCS#11?
I'm looking at implementing support for unblocking a locked PIN in my application, but looking at OpenSC that doesn't seem to be possible. In fact, there are a number of issues along the way. The correct way of unblocking a PIN, as far as I understand, is calling C_Login(CKU_SO) followed by C_InitPIN(). This is how pkcs11-tool does it, as well as a sample for pykcs11. Now for the problems: 1. C_Login(CKU_SO) doesn't seem to work on any of my PKCS#15 cards. Looking at the code, it seems OpenSC wants to do a VERIFY operation, but that requires a reference number which in turn requires a PIN object for the SO PIN, which doesn't exist on any of my cards. 2. C_InitPIN() tries to use pkcs15init to create an entirely new PIN object, not reset the existing one. I have little hopes this will result in anything even remotely close to what I'm after. Since pkcs15-tool -u works, I'm assuming what I want is to gain access to sc_pkcs15_unblock_pin(). But it doesn't seem like PKCS#11 ever maps to this, so is that API simply insufficient for unblocking cards? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
