Menu
▾
▴
Re: [Opensc-devel] Question about C_InitToken reinitialize
|
From: Bob B. <fig...@gm...> - 2018-10-30 02:01:16
|
Hi Douglas, Thank you for your reply. Do you have a specific card in mind? - No specific card, I have a software that simulates the smart card operations, I also implemented my own OpenSC driver for this. Do you expect the user to do their own card administration? i.e. know the SO pin? - No, the administrator that knows the SO pin will be different from the user (that knows user pin). Maybe my concern is summarized with the concern about the C_InitToken implementation. Because I got confused with the PKCS# 11 definition of the C_InitToken (the one I mentioned previously). I am not sure if I need to change the implementation of C_InitToken and add the verify/validate of the SO pin inside the C_InitToken or do I do it on the client application layer, call C_Login (for SO pin) first, if success proceed with C_InitToken, if fail return error. Another concern is about the security, with the current implementation of C_InitToken, if someone got access to the PKCS# 11 API, he could just call the C_InitToken and erase the contents of the card without knowing the SO pin or the user pin. How do you usually handle/secure this kind of stuff? Are you trying to be a card issuer and do remote administration over the web? - None of anything like that as of now. Sorry if I am having problem explaining the problem, I am new to PKCS# 11 and to OpenSC. Your expert view on this is greatly appreciated. Cheers, fightingsibuyas On Tue, Oct 30, 2018 at 1:19 AM Douglas E Engert <dee...@gm...> wrote: > You asked about OpenSC documentation. OpenSC attempts to present a PKC#11 > interface for use by a user. But it really comes done to what the specific > token (card) allows. Many of the tokens do not support what you are trying > to do. OpenSC includes a number of card specific tools to help administer > cards. > > In many security environments, the card is issued by some organization > (company/university/gov) where the user never knows the SO pin (if there is > one) Many of these cards use a 3DES or AES key for authentication to do > card administration. The card administration is done in a secure > environment so the SO pin and 3DES or AES keys are kept secure. OpenSC is > not trying to support such environments. > > It sounds like you are in an environment where the user should know the SO > pin, as your question what if the user lost/forgot the SO pin. My answer > would to buy a new card. > > So some questions about what are you really trying to do: > Do you have a specific card in mind? > Do you expect the user to do their own card administration? i.e. know the > SO pin? > Are you trying to be a card issuer and do remote administration over the > web? > (As hinted at above there are many security issues with doing this.) > > > > > > > On Mon, Oct 29, 2018 at 9:03 AM Bob Backlund <fig...@gm...> > wrote: > >> Hi Paul, >> >> Thank you for your reply. I appreciate your help, I have some comments >> below. >> >> Hi! It seems that the SO PIN you passed should be checked by the token >> itself. In other words it can be stated as: in order to re-initialize the >> token you have to *log on* to that token. >> - Do you mean that before I call the C_InitToken that the verification >> of the SO PIN should be done outside the C_InitToken, like calling the >> C_Login before the C_InitToken? The PKCS# 11 statement I mentioned is under >> the C_InitToken definition from my understanding the verification of the SO >> PIN should be done inside the C_InitToken. I am testing the C_InitToken >> with two test case, first test case is that I give the correct SO PIN, >> second case is I give the wrong SO PIN. On the first case my expectation is >> that C_InitToken will reset the card (deleting the deletable objects >> inside, reverting to the state when the first C_InitToken was called), >> second test case I expect the C_InitToken will give me an error and not >> reset the card. >> >> But that leads to the following problem: what to do if you forget the SO >> PIN and that is why you want to *reset* the token completely? >> - The PKCS# 11 document answered that one here's what they said. >> If the SO PIN is lost, then the card must be reinitialized using a >> mechanism outside the scope of this standard. >> >> Second, if you look at the implementation of init_token() at >> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the >> existing SO PIN. And that is true for the cards and tokens I'm working >> with: I enter there any SO PIN I want and get a newly initialized token >> with no data on it. >> - I understand, your explanation makes sense with the current source >> code. But my problem is that, is it safe that way, because anyone can just >> call the C_InitToken to reset the card and deleting all the keys inside. >> How do you secure yourself from this scenario? >> >> Here's longer definition of C_InitToken from the PKCS# 11 document. >> C_InitToken initializes a token. slotID is the ID of the token’s >> slot;pPin points to the SO’s initial PIN (which need not be >> null-terminated); ulPinLen is the lengthin bytes of the PIN; pLabel points >> to the 32-byte label of the token (which must be padded with blank >> characters, and which must not be null-terminated). This standard allows >> PIN values to contain any valid UTF8 character, but the token may impose >> subset restrictions. Ifthe token has not >> beeninitialized(i.e.newfromthefactory),thenthe pPin parameterbecomes the >> initial value of the SO PIN. If the token is being reinitialized, the >> pPin parameter is checkedagainsttheexistingSOPINtoauthorize the >> initialization operation. In both cases, the SOPINisthevaluepPin after the >> function completes successfully. If the SO PIN is lost, then >> thecardmustbereinitializedusingamechanismoutsidethescopeofthisstandard.The >> CKF_TOKEN_INITIALIZED flag in the CK_TOKEN_INFO structure indicates the >> action thatwillresultfromcalling C_InitToken.Ifset,thetokenwillbe >> reinitialized,andtheclient must supply the existing SO password in pPin. >> Source: https://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf >> >> Thank you for your help! >> >> fightingsibuyas >> >> >> On Mon, Oct 29, 2018 at 7:14 PM Paul Wolneykien <ma...@al...> >> wrote: >> >>> 29.10.2018 12:59, Bob Backlund пишет: >>> > Hi, >>> > >>> > Just some question on the C_InitToken implementation of OpenSC, the >>> > PKCS#11 document states the following below. >>> > / >>> > If the token is being reinitialized, the *pPin parameter is checked >>> > against the existing SO PIN* to authorize the initialization >>> operation. >>> > / >>> > When the token is reinitialized, the C_InitToken should verify the PIN >>> > passed to it with the one provided on the first initialization. >>> > >>> > I tried to trace the source code but it seems this is not handled on >>> the >>> > C_InitToken layer, the C_InitToken will just pass the data (pin, pin >>> > length, label) to PKCS#11 framework, or the pkcs15_initialize function. >>> >>> Hi! It seems that the SO PIN you passed should be checked by the token >>> itself. In other words it can be stated as: in order to re-initialize >>> the token you have to *log on* to that token. But that leads to the >>> following problem: what to do if you forget the SO PIN and that is why >>> you want to *reset* the token completely? >>> Second, if you look at the implementation of init_token() at >>> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the >>> existing SO PIN. And that is true for the cards and tokens I'm working >>> with: I enter there any SO PIN I want and get a newly initialized token >>> with no data on it. >>> >>> >>> > On this function, it will check if there is an implementation for the >>> > SC_CARDCTL_PKCS11_INIT_TOKEN command on the card level (card-*), the >>> > data is passed on this function. Most of the driver did not implement >>> > this one. >>> > After the call on this function, sc_pkcs15init_erase_card is also >>> > called, but data is not passed. >>> > >>> > After this, pkcs15nit_add_app is called, this is the function that do >>> > the initialization, but until here the existing SO validation was not >>> > handle, data was passed on this function. >>> > >>> > So, my question is if wanted to support the existing SO validation (as >>> > stated in PKCS#11 document) for the C_InitToken, what will be my >>> > approach? I was thinking of implementing SC_CARDCTL_PKCS11_INIT_TOKEN, >>> > but this is on the card level and it doesn't know anything about the >>> > PKCS#11 object or the PKCS# 15 structure. >>> > >>> > I appreciate if someone can put me on the direction or at least the a >>> > document that I can read that discusses this part of OpenSC. >>> > >>> > Thank you very much! >>> > >>> > >>> > Cheers, >>> > >>> > fightingsibuyas >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensc-devel mailing list >>> > Ope...@li... >>> > https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> > >>> >>> >>> >>> _______________________________________________ >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > |
