Bug #1369

PKCS#11 reauthentication for each signature/decryption seems to be broken...

Added by Luka Logar over 6 years ago. Updated about 6 years ago.

Target version:
Start date:
Due date:
Estimated time:
Affected version:


If I read the code correctly, it looks like PIN is only known while in load_pin()/load_from_smartcard()/pkcs11_private_key_connect() functions.
When the sign() function gets called at a later time, PIN is no longer known and the reauthentication fails with "private key requires reauthentication, but no PIN found" error.

Associated revisions

Revision 2eb89ee1 (diff)
Added by Tobias Brunner about 6 years ago

stroke: Permanently store PINs in credential set

This fixes authentication with tokens that require the PIN for every

Fixes #1369.


#1 Updated by Tobias Brunner over 6 years ago

  • Status changed from New to Feedback
  • Target version set to 5.5.0

"private key requires reauthentication, but no PIN found"

Yes, for tokens that require reauthentication, i.e. the PIN has to be provided for every signature, the current code doesn't work. At least in charon this always seems to have been the case, the stroke plugin never stored PINs in a permanent credential set (they are only provided temporarily while the private key is loaded initially - since a PKCS#11 session is kept open this works fine if the token doesn't require reauthentication). Not sure if that was done on purpose or is just an oversight.

I guess there are two options, either store all PINs in stroke's credential set after successfully loading associated keys, or store them on the key objects themselves, but only if reauthentication for a token/key is actually required. The latter would avoid keeping PINs in memory over longer periods of time unless it's required, on the other hand, it wouldn't allow changing the PIN at runtime (not sure if that's even possible while a PKCS#11 session is open).

What's missing too is support to define PINs in swanctl.conf.

#2 Updated by Tobias Brunner over 6 years ago

  • Category set to libstrongswan

The second option has a serious disadvantage: It wouldn't allow a specialized credential set that prompts the user for the PIN everytime it's required to do so during reauths. I pushed a change that caches the PIN in the stroke plugin to the 1369-pins branch. I also tested changing PINs and that works despite any open sessions, however, because the tokens I have don't require reauthentication and due to the open session no login with the new PIN was required.

#3 Updated by Tobias Brunner about 6 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Also available in: Atom PDF