PKCS#11
|
| Cryptographic Token Interface Standard |
PKCS#11 |
Session events cause the session state to change. The following table describes the events:
| Event | Occurs when... |
| Log In SO | the SO is authenticated to the token. |
| Log In User | the normal user is authenticated to the token. |
| Log Out | the application logs out the current user (SO or normal user). |
| Close Session | the application closes the session or closes all sessions. |
| Device Removed | the device underlying the token has been removed from its slot. |
When the device is removed, all sessions of all applications are automatically logged out. Furthermore, all sessions any applications have with the device are closed (this latter behavior was not present in Version 1.0 of Cryptoki)"an application cannot have a session with a token that is not present. Realistically, Cryptoki may not be constantly monitoring whether or not the token is present, and so the token's absence could conceivably not be noticed until a Cryptoki function is executed. If the token is re-inserted into the slot before that, Cryptoki might never know that it was missing.
In Cryptoki Version 2.1, all sessions that an application has with a token must have the same login/logout status (i.e., for a given application and token, one of the following holds: all sessions are public sessions; all sessions are SO sessions; or all sessions are user sessions). When an application's session logs into a token, all of that application's sessions with that token become logged in, and when an application's session logs out of a token, all of that application's sessions with that token become logged out. Similarly, for example, if an application already has a R/O user session open with a token, and then opens a R/W session with that token, the R/W session is automatically logged in.
This implies that a given application may not simultaneously have SO sessions and user sessions open with a given token. It also implies that if an application has a R/W SO session with a token, then it may not open a R/O session with that token, since R/O SO sessions do not exist. For the same reason, if an application has a R/O session open, then it may not log any other session into the token as the SO.