Menu
▾
▴
Re: [Opensc-devel] Question about C_InitToken reinitialize
|
From: Bob B. <fig...@gm...> - 2018-12-19 02:37:40
|
Hi Douglas, Thank you for your explanation, I agree it does get me confused at times, I decided to just handle it on the client application side, we can consider my question answered. Thank you again. Cheers, fightingsibuyas On Wed, Oct 31, 2018 at 1:04 AM Douglas E Engert <dee...@gm...> wrote: > > There are other simulated smart card software available, and a number on > github > Search for github smartcard emulation. Check this one out: > https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html > > When writing a simulator it is easy to mix up the security layers between > the OpenSC driver and the simulated card. The reason for a physical card is > to protect the keys and PINs behind the cards security layer. All of the > application and middleware like PKCS#11 and OpenSC are only tools to make > it easier to access the card. Anyone can take the OpenSC code and hack it > anyway they want. > i.e. "gain access to the PKCS#11 API" But they can not hack the physical > card. It has its own protection including physical protection to destroy > memory if one tries to tamper with the card .(Better to destroy the card > then to expose the keys.) So you need to define first how your simulated > card is protected. Could a hacker gain access to you system or its backups > and copy the files and do a offline attack? Would the files be encrypted, > and how is the encryption key protected? > > The C_Login for SO pin should result in the driver sending this to the > card usually by a VERIFY APDU. Your simulated card will then have to > determine if it is valid, and set some login state. > Then as other APDUs are sent to the card it can check if the login state > is still valid. Some APDUs or resets will cause the login state to be lost. > The card should also keep track of consecutive failures > of the SO and User points and lock the use of the PIN. > > > On Mon, Oct 29, 2018 at 9:01 PM Bob Backlund <fig...@gm...> > wrote: > >> 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 >>>> >>> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > |
