Re: [Opensc-devel] Question about C_InitToken reinitialize

[Douglas E E. <dee...@gm...>]

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
>