3

The CKA_TOKEN attribute identifies whether the object is a token object or a session object.

We can believe that when the PKCS#11 object has CKA_TOKEN attribute set to true, then it is securely stored inside memory of PKCS#11 enabled device. For example secret AES key, especially when it is not extractable.

What about session keys and their security?

When a session is closed, all session objects created by the session are destroyed automatically, even if the application has other sessions “using” the objects.

So anyone able to eavesdrop my session will be able to see the clear-text value of my secret key? For example when I would like to translate key between two end points, it has to be unwrapped and wrapped with different key, meaning it should be somewhere in session in clear-text for some short time. Is it in system memory? Or is it somehow secured?

user1563721
  • 1,099
  • 11
  • 22

1 Answers1

4

Physical storage characteristics are not part of the definition of PKCS#11. PKCS#11 is an API: it defines the behaviour of the library with regards to function calls, not with regards to actual technology. A purely software PKCS#11 library, with all keys in RAM, is perfectly possible (and that's exactly what the Firefox Web browser is using internally).

With CKA_TOKEN enabled, the key is supposed to be permanent, i.e. you will find it back after opening a new session. It does not necessarily entail any kind of protection, either while being used or while stored. There is another attribute that is called CKA_EXPORTABLE, that declares whether the key may be exported or not; but, there again, it does not qualify attacks, only what you will get if you call the export function. Depending on how the PKCS#11 library is implemented, all keys may float in RAM at some point.

If you want to know where exactly your key will be, then you will have to look at the documentation for the device or system for which you have a PKCS#11 library. If the device is a HSM and the HSM documentation guarantees that private keys stored in the HSM never leave it, then you know that they won't be copied in the RAM of the PC -- not because of any PKCS#11-related attribute, but because the HSM makes it so. The PKCS#11 library is merely a consumer of the HSM services.

That being said, it is possible to make some inferences. For instance, if your crypto device is a smart card, then its I/O capabilities are very limited (9600 bauds is typical) so chances are that any bulk encryption (AES) provided by the PKCS#11 API would be handled in software, so your secret unwrapped AES key would really be somewhere in the RAM of the PC.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949