This article is valid from Personal Desktop Client 5.3
This article describes the PIN caching mode for Nexus Personal Desktop Client.
When Personal Desktop Client is run in PIN caching mode, it is possible to cache PIN codes in the PKCS#11 and the minidriver/CSP (Windows only) modules. Personal Desktop Client can also run in PIN non-caching mode. Then no PIN caching will take place.
PIN caching applies to all tokens; both smart card and software tokens.
When the term card is used in this article it only applies to smart cards. When the term token is used it applies to both smart cards and software tokens.
Step-by-step instructions
Run Personal Desktop in PIN caching mode
To enable PIN caching mode, set the configuration parameters
MD_EnableCachePIN,CSP_EnableCachePINandP11_EnableCachePINto1in personal.cfg.
Set the parameters to 0 to disable PIN caching mode.
Description of PIN caching mode
Each process that loads the PKCS#11 and the CSP modules has its own PIN caching environment.
When a successful login is performed, the PIN is internally logged out and stored in the PIN caching environment in the given process. The cached PIN will later be used as soon as a private operation is performed. And then, as soon as a private operation is performed, the PIN is internally logged out.
If the CSP and PKCS#11 are loaded into the same process, they will share PIN caching environment. When running an application in PIN caching mode, the card is always accessible from other applications since the card will always be released when an operation that needs private card access has been performed.
PIN caching when using minidriver is done in Base CSP layer by Windows itself, instructed by the Personal Desktop minidriver module based on a configuration setting. This applies for Windows only.
A PIN is cached on a token basis. In one process, all contexts accessing a specific token will have access to the cached PIN code. The PIN code is cleared from the cache as soon as the last context of a specific token is released, or when the token is removed from its reader.
For PKCS#11
Since every PKCS#11 slot represents one PIN, the PIN is cached on a slot basis. In one process, all sessions accessing a specific slot will have access to the cached PIN code. As soon as C_Logout is called, or the last session to a specific slot is closed, the PIN is cleared from the cache. Also, if the specific token is removed, the PIN is cleared form the cache.
Description of PIN non-caching mode
In PIN non-caching mode the calling application has the control of the login states of the tokens. If the CSP and PKCS#11 are loaded into the same process, they will share the login state of the token. If no PIN caching is used, the card will be exclusively locked by the calling process as long as the user is logged in. Thus, it will not be accessible from other applications until it is released.
For Minidriver
This section only applies to the Windows platform.
PIN caching in Base CSP layer is disabled by minidriver module and user needs to enter PIN every time operation requiring it is requested.
For CSP
This section only applies to the Windows platform.
If a context is logged into a token, that logged in state can be used by all other contexts accessing that specific token. The token will be logged out as soon as the last context to the token is released. A card will not be accessible to other processes until the card is logged out. It is possible to configure the CSP to always log out after it has performed an operation that needs logged in state. The configuration parameter is CSP_LogoutAfterSign and when set to 1, the token is logged out after a private operation.
For PKCS#11
If a session is logged into a slot, the slot will be accessible from all other sessions to that slot in the calling process. The token will be logged out as soon as C_Logout is called, or all sessions to a given slot are closed. A card will not be accessible to other processes until the card is logged out. It is possible to configure the PKCS#11 to always log out after it has performed a signing operation. The configuration parameter is P11_LogoutAfterSign and when set to 1, the token is logged out after a signing operation.
Configuration details
Assume that a user has logged into a token in order to sign a hash with his private key present on the token. The table below, which applies to the Windows platform only, shows the behavior of the CSP in different combinations of the flags CSP_EnableCachePIN and CSP_LogoutAfterSign.
Flag | CSP_EnableCachePIN=0 | CSP_EnableCachePIN=1 (default) |
|---|---|---|
CSP_LogoutAfterSign=0 (default) | A card that is logged in is locked by the calling application until the last context to the card is released. | A card is released after every private operation and will thus be accessible. |
CSP_LogoutAfterSign=1 | A logout is forced after every private operation. As a result, the user will be asked for his PIN prior to every operation requiring that he is logged in. | A logout is forced after every private operation. As a result, the user will be asked for his PIN prior to every operation requiring that he is logged in. |
The table below shows the behavior of the PKCS#11 in different combinations of the flags P11_EnableCachePIN and P11_LogoutAfterSign.
Flag | P11_EnableCachePIN=0 | P11_EnableCachePIN=1 (default) |
|---|---|---|
P11_LogoutAfterSign=0 (default) | A card will not be accessible from other applications as long as it is in logged in state. | The token is internally released after every private operation. A card will be accessible from other applications even if it is logged in. |
P11_LogoutAfterSign=1 | A logout is forced after every signing operation. A card will not be accessible from other applications as long as it is in logged in state. | A logout is forced after every signing operation. The token is internally released after every private operation. A card will be accessible from other applications even if it is logged in. |
Force login before sign
You can configure Personal to require a PIN-reverification prior to a signing operation with a key, when the key or the corresponding certificate has a specific key usage.
The configuration parameter is ForceLoginBeforeSignKeyUsage in the file personal.cfg. (See the sample configuration file for more information about this parameter.) Only the key usage extension Non-Repudiation is supported.
Example: If PIN-reverification shall be performed prior to every non-repudiation signature, configure Personal as follows for every application this setting shall influence:
ForceLoginBeforeSignKeyUsage=0x40