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.
I discovered this bug when I found that I could reset my NSS databases with certutil -T -d . without providing any password.
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.
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 C_InitToken).
Sounds like an issue when in FIPS mode, and not otherwise.
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: C_InitToken ... 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.
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?
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-
Assignee: nobody → rrelyea
Priority: P3 → P2
Target Milestone: --- → 3.12.7
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. bob
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.