Cryptographic Token Interface Standard |
PKCS#11 |
Note: The information in this section, 6.7, related to secondary authentication in Cryptoki has been deprecated in PKCS #11 v2.11 and higher. It is included here for reasons of backward compatibility. New Cryptoki implementations and Cryptoki aware applications should not implement these features. It will not be present in the next major revision of the specification. An alternative approach is presented in Appendix D.
Cryptoki allows an application to specify that a private key should be protected by a secondary authentication mechanism. This mechanism is in addition to the standard login mechanism described in section 6.6 for sessions. The mechanism is mostly transparent to the application because the Cryptoki implementation does almost all of the work.
The intent of secondary authentication is to provide a means for a cryptographic token to produce digital signatures for non-repudiation with reasonable certainty that only the authorized user could have produced that signature. This capability is becoming increasingly important as digital signature laws are introduced worldwide.
The secondary authentication is based on the following principles: