Re: [Opensc-devel] Question about C_InitToken reinitialize

[Bob B. <fig...@gm...>]

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
>