NSC_InitToken ignores its pPin argument.



13 years ago
10 years ago


(Reporter: wtc, Assigned: rrelyea)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: FIPS)


(1 attachment, 1 obsolete attachment)



13 years ago
NSC_InitToken ignores its pPin argument.

The pPin argument is the initial SO (Security Officer) PIN
if the token has not been initialized (i.e., new from the
factory), or should be checked against the existing SO PIN
if the token is being reinitialized.

Comment 1

13 years ago
I discovered this bug when I found that I could reset my
NSS databases with

    certutil -T -d .

without providing any password.

Comment 2

13 years ago
Isn't this done on purpose ? Otherwise you can't reinitialize the softoken if you lost the password. You would have to erase the NSS key DB manually, which would require inside knowledge of softoken.


Comment 3

13 years ago
I am fine with resolving this bug INVALID or WONTFIX
because the user can also delete the NSS databases without
entering a password.  I just wanted to find out if this
nonconformance to PKCS #11 was intentional.  If so, we
should add a comment to NSC_InitToken and possibly
PK11_ResetToken (the only NSS function that calls
Sounds like an issue when in FIPS mode, and not otherwise.

Comment 5

13 years ago
Created attachment 220992 [details] [diff] [review]
Unimplement FC_InitToken

Now I remember that FC_InitToken originally did nothing
and simply returned CKR_HOST_MEMORY.  I changed FC_InitToken
to call NSC_InitToken in NSS 3.11 when I fixed bug 298517.
So perhaps we can consider that change to be a regression
in FIPS mode.  This patch backs out that change to FC_InitToken
and adds a comment to NSC_InitToken.  Bob, I'm not sure I wrote
the comment accurately.  Please provide a better comment in
your code review.

PKCS #11 v2.20 (p. 113) talks about the case when the
password is lost:

  If the SO PIN is lost, then the card must be reinitialized
  using a mechanism outside the scope of this standard.

So perhaps the proper way to implement certutil's -T command
("Reset the Key Database or token") is to first delete the
key database (using a non-PKCS #11 method), and then call
C_InitToken to create a new key database.
Attachment #220992 - Flags: review?(rrelyea)

Comment 6

13 years ago
Created attachment 220994 [details] [diff] [review]
Unimplement FC_InitToken, v1.1

The previous patch has a typo.  I also found an out-of-date
comment in NSC_InitToken that should be removed.

I'm not sure if we should back out the FC_InitToken change
or just document its current behavior.  Do you think it is
a problem that FC_InitToken can reinitialize the key database
without checking the (SO) PIN in FIPS mode?
Attachment #220992 - Attachment is obsolete: true
Attachment #220994 - Flags: review?(rrelyea)
Attachment #220992 - Flags: review?(rrelyea)

Comment 7

13 years ago
Comment on attachment 220994 [details] [diff] [review]
Unimplement FC_InitToken, v1.1

This patch will break mozilla's database reset button.
Attachment #220994 - Flags: review?(rrelyea) → review-
Priority: -- → P3


10 years ago
Blocks: 459298
Assignee: nobody → rrelyea
Whiteboard: FIPS
Priority: P3 → P2
Target Milestone: --- → 3.12.7

Comment 8

10 years ago
So there is a bootstrap problem in softoken. Softoken does not now, nor never has, supported the SO pin (per se). We have a fixed SO pin which is the empty string. The SO can only reset the database. Resetting the pin with the SO in NSS results in the loss of all key material (since the SO isn't trusted).

This feature is used by applications like firefox to reset the database password if the user forgets it, so I'm marking this WONTFIX.

Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.