Re: Question about C_InitToken reinitialize

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 <[email protected]> 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 <[email protected]>
> 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 <[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
>>
>

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