Need an option to specify no PIN is required for login

[matthauck]

Some HSM's that I am testing (Thales) with do not require entering a PIN when run with a wrapper command. In this scenario, all the application needs to do is call C_Login with an empty pin. Right now, however, when invoked with an empty pin, libp11 currently blocks on stdin waiting for the user to enter a PIN -- not ideal for a backend server. Can workaround for now by entering a dummy pin, but it would be good to have an openssl engine control command that tells the library not to prompt for a pin.

I'm thinking I would call it NO_PIN or NO_PROMPT_PIN, and would be a "no value" control command like VERBOSE is currently. Does that sound reasonable?

[matthauck]

Actually, i think this is not required. Looks like I was not setting the PIN value when I had an empty string, and thus never specified PIN at all, leaving it NULL, thus prompting for the pin. Specifying an empty string for PIN works fine and libp11 does not prompt for the pin. 👍

[matthauck]

Hmm. Maybe this is still a good thing to add. The PKCS11 spec says:

If the token has a “protected authentication path”, as indicated by the CKF_PROTECTED_AUTHENTICATION_PATH flag in its CK_TOKEN_INFO being set, then that means that there is some way for a user to be authenticated to the token without having the application send a PIN through the Cryptoki library. One such possibility is that the user enters a PIN on a PINpad on the token itself, or on the slot device. Or the user might not even use a PIN—authentication could be achieved by some fingerprint-reading device, for example. To log into a token with a protected authentication path, the pPin parameter to C_Login should be NULL_PTR.

(emphasis added)

Looks like it would be a good idea to allow a code path to say that the PIN is left intentionally unset.

[matthauck]

err, actually, looks like libp11 is already doing the right thing and checking for this flag, but the HSM is not setting that flag. 😞

[dwmw2]

FWIW GNOME keyring also uses CKF_PROTECTED_AUTHENTICATION_PATH, so it should be relatively easy to test this even without special hardware.

[dengert]

I don't under stand what you mean by: "GNOME
  keyring also uses CKF_PROTECTED_AUTHENTICATION_PATH". Do
    you mean: GNOME keyring understands
      that if PKCS#11 C_GetTokenInfo returns CKF_PROTECTED_AUTHENTICATION_PATH
          it knows what that means?  


PKCS#11 is telling the calling application that PKCS#11 has a
  way to authenticate the user without the application providing a
  PIN during C_Login. For example C_GetTokenInfo returns CKF_PROTECTED_AUTHENTICATION_PATH
  if the token is using a reader with a PIN PAD. So if
  C_Login is called with a NULL pin, PKCS#11 will use the other
  authentication path, i.e. the pin pad reader. If C_Login is passed
  a PIN, it will try and use it, but most PIN PAD readers will not
  pass a PIN from the host to the token, as the whole point is using
  is PIN PAD reader is to not have the PIN exposed to the host's
  software.  


On 8/12/2016 5:05 AM, dwmw2 wrote:


  FWIW GNOME keyring also uses CKF_PROTECTED_AUTHENTICATION_PATH,
    so it should be relatively easy to test this even without
    special hardware.
  —
    You are receiving this because you are subscribed to this
    thread.
    Reply to this email directly, view
      it on GitHub, or mute
      the thread.







  {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/OpenSC/libp11","title":"OpenSC/libp11","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/OpenSC/libp11"}},"updates":{"snippets":[{"icon":"PERSON","message":"@dwmw2 in #92: FWIW GNOME keyring also uses `CKF_PROTECTED_AUTHENTICATION_PATH`, so it should be relatively easy to test this even without special hardware."}],"action":{"name":"View Issue","url":"https://github.com/OpenSC/libp11/issues/92#issuecomment-239409431"}}}


-- 

Douglas E. Engert DEEngert@gmail.com

[dengert]

From the original posted question, is the HSM not setting the CKF_PROTECTED_AUTHENTICATION_PATH because it is saying no pin or any other authentication path is even used. For example some keys may not be protected at all. (PIV has one key used to have the card authenticate itself. Used for physical access for door locks. It proves the card is being used, but does not prove the user knows any PIN.)

CKF_PROTECTED_AUTHENTICATION_PATH says there is some authentication needed to access the token.

[dwmw2]

@dengert GNOME keyring provides a PKCS#11 token of its own. That token sets the CKF_PROTECTED_AUTHENTICATION_PATHflag, It wants you to callC_Login()` with a NULL password, and when you do it'll bring up a modal dialog in the UI to ask for the passphrase (if it hasn't already got it from PAM as you logged in, etc.).

So if we want to test libp11 with tokens that use CKF_PROTECTED_AUTHENTICATION_PATH, we don't have to look far.