|
Description
|
the engine caches sessions it creates, together with keys that were created during the last time the session was (re)used. When the thread is done, the session is returned to the pool and awaiting another thread to pick it up.
when the new thread picks up the session, it checks whether the keys contained in the session are the same as the keys planned for the current operation. If they are, the deletion of the old PKCS#11 object and creation of new object is skipped, and thus saving some time under assumption that creating objects in underlying PKCS#11 tokens might be quite an expensive operation.
the problem is that with symetric keys, C_(Decrypt|Encrypt)Final() is not called before the session it returned to the pool. This leads to a situation that is implementation dependent - we use the context that might have some final data in it.
we must either always to Final the context before returning the session or always to create a new object when the session is picked up from the pool. The 2nd solution might be easier and probably sufficient given the fact that this error is in the engine for a long time and it wasn't discovered until now. In other words, the perfomance gains in that rare situation might not be worth the more complex code.
why the situation where symetric keys are reused is rare? It stems from the way how symetric keys are used. Usually, symetric keys are session keys - generated once, used once, then destroyed.
|