pkcsconf -u is suppose to initialize the user pin. But it does not appear to do this for tpm token. Had to do a pkcsconf -p to initialize and set user pin for tpm. However, we only have to do a pkcsconf -u on the other tokens to initialize and set the user pin. Why is this different for tpm?
We pretty much ignore initializing and setting the user pin in C_InitPin() for tpm. Whereas the other tokens do it and save to NVTOK.DAT the fact that it has been initialized. So now I understand why you return after token_specific_init_pin and don't save anything to NVTOK.DAT. That is the way it was done before. And also why I did not understand because I am thinking it should have same behavior as other tokens. Instead, tpm waits to C_SetPin to set user pin and save the fact that it has been initialized into NVTOK.DAT.
I looked at the pkcs#11v2.20 spec and it says the following about C_InitPIN:
If the token has a protected authentication path other than a PINpad, then it is token dependent whether or not C_InitPIN can be used to initialize the normal user’s token access. "
And it has the exact same thing for C_SetPIN.
The flag does not appear to be set in tpm to indicate it has a protected authentication path.
And if it does or doesn't then I cannot help but think C_InitPIN and C_SetPIn for the user pin should have similar behavior.
This issue was migrated from https://sourceforge.net/p/opencryptoki/bugs/124/
pkcsconf -uis suppose to initialize the user pin. But it does not appear to do this for tpm token. Had to do apkcsconf -pto initialize and set user pin for tpm. However, we only have to do apkcsconf -uon the other tokens to initialize and set the user pin. Why is this different for tpm?We pretty much ignore initializing and setting the user pin in C_InitPin() for tpm. Whereas the other tokens do it and save to NVTOK.DAT the fact that it has been initialized. So now I understand why you return after token_specific_init_pin and don't save anything to NVTOK.DAT. That is the way it was done before. And also why I did not understand because I am thinking it should have same behavior as other tokens. Instead, tpm waits to C_SetPin to set user pin and save the fact that it has been initialized into NVTOK.DAT.
I looked at the pkcs#11v2.20 spec and it says the following about C_InitPIN:
And it has the exact same thing for C_SetPIN.
The flag does not appear to be set in tpm to indicate it has a protected authentication path.
And if it does or doesn't then I cannot help but think C_InitPIN and C_SetPIn for the user pin should have similar behavior.
This issue was migrated from https://sourceforge.net/p/opencryptoki/bugs/124/