Re: Question about C_InitToken reinitialize

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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
>> 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
>>> > [email protected]
>>> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

_______________________________________________
Opensc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensc-devel