1

The question is about where session objects are created and stored - on a token or in RAM of an application that uses a pkcs11 library? It seems that pkcs11 specification does not differentiate them this way, which could mean that all objects are created on a token - being a RAM (software) object is a too important property to not be mentioned specifically. Yet, I have arguments for session objects to be RAM objects. A couple of them are:

  • the name of the CKA_TOKEN attribute implies that it is either a "token" object (CKA_TOKEN = CK_TRUE) or "not token" object (CKA_TOKEN = CK_FALSE). So, a session object is a "not token" object. Hence, it is a RAM object;
  • general purpose smart cards, which are obvious candidates for a token, usually do not have a concept of session objects apart from some specific cases.

So, is there a definite answer to my question? What is a common approach that developers take?

Improve this question
2
  • This is an implementation detail. Session objects from what API? Commented Jul 6 at 2:16
  • @TimRoberts, It is straight from pkcs11 specification. So, pkcs11 API. The specification is not a stranger to stating that some things are implementation dependent. It does not say that about session objects. That makes me think that it might not be implementation dependent. Commented Jul 6 at 18:26

1 Answer 1

Reset to default
1

For a good understanding of session objects and the difference with token objects, the PKCS #11 Usage Guide is probably more helpful than the PKCS#11 Base specification. Section 2.3 (Logical view of a token) of the Usage Guide says: Objects are also classified according to their lifetime and visibility.  “Token objects” are visible to all applications connected to the token that have sufficient permission, and remain on the token even after the “sessions” (connections between an application and the token) are closed and the token is removed from its slot.  “Session objects” are more temporary: whenever a session is closed by any means, all session objects created by that session are automatically destroyed.  In addition, session objects are only visible to the application which created them.

Also for more details on sessions and session objects, you may check the section 2.6 (Sessions). In particular, section 2.6.4 explains the differences in terms of permissions for session objects and token objects, depending on the session type. For instance, in a read-only session, you can still create/modify session objects, but not token objects.

As a developer, if you don't need any persistence of the object (beyond the session lifetime) or to make it visible to other applications, then it's usually safer and likely more efficient to use session objects; else you have to use token objects. Actually, the more efficient depends on the implementation in the end, because as Tim Robert mentions, the storage mechanism is implementation-specific (check the documentation of the hardware token and associated PKCS#11 library), not in the standard. So you may assume that most implementations use memory instead of persistent storage for session objects, and therefore they should be processed faster, but ultimately you would need a little benchmark on your particular hardware token to confirm that.

EDIT 2025-07-07

For example, there are certified PKCS#11 hardware implementations (e.g. some HSMs) that allow to store the session (and/or token) objects outside the hardware token, i.e. on the host of the PKCS#11 app/library (probably in RAM for session objects, but again, this is implementation-specific), and in this case, they use a key wrapping mechanism to protect the private/secret key objects from being exposed on the host; i.e. these keys are wrapped with a wrapping key inside the hardware token before going out to the host (or if a key hierarchy is used, only the root wrapping key needs to be inside the hardware token). Then the key is unwrapped inside the token when it is needed for a PKCS#11 crypto operation. So some PKCS#11 libraries for particular smartcards may do this as well, but this is vendor-specific (looking at the product documentation or implementation code of the PKCS#11 library for the smartcard might help).

Check also this answer: https://security.stackexchange.com/questions/117624/pkcs11-session-object-security

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

This user guide thing-y is (was in pkcs11 v2.20) a part of the specification. It does tell how session objects work. It does not tell - explicitly - where they are stored. It seems by use memory instead of persistent storage you mean memory of a token. In the case of general purpose smart cards, I do not have control over that and it is going to be persistent storage. My question is whether it should be memory of an application.
Are you implementing the PKCS#11 library by yourself or using the one from the smartcard vendor?
I am implementing.
In case you are implementing I would definitely consider RAM, also because otherwise you'd have to implement some kind of cleanup procedure for the created objects. Especially keys need to be get rid of in a secure fashion; just removing the reference to it won't cut it. Of course there are tricks such as creating a session key and encrypting the objects with that (an implementation detail that PKCS#11 vendors that store objects outside of the hardware token itself will most definitely use).

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.