[Bug 3635] New: ssh-add -s always asks for PKCS#11 PIN

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3635

            Bug ID: 3635
           Summary: ssh-add -s always asks for PKCS#11 PIN
           Product: Portable OpenSSH
           Version: 9.0p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh-add
          Assignee: unassigned-bugs at mindrot.org
          Reporter: quirin.bitter at zg.ch

Hi there!

Our HSM provides a PKCS#11 library to use it with software like the
OpenSSH client.
Credentials for the HSM are handled by a configuration file, read by
the PKCS#11 library, outside of the PKCS#11 protocol.
Therefore, no interactive PIN entrance is necessary, and skipping it by
providing an empty PIN, i.e., just pressing enter at the prompt,
hinders our automation.

When using a key, stored on the HSM, to login via ssh, we realized that
ssh -I /path/to/hsm_pkcs11_library and adding a key to a ssh agent with
ssh-add -s /path/to/hsm_pkcs11_library behaves differently.
Login with ssh -I works without any user interaction, but ssh-add -s
always asks interactively for the PIN.

Investigating this behavior, the following was found.

There seem to be two ways for an PKCS#11 token to signalize that no PIN
is required through the PKCS#11 library.
1. By not setting the CKF_LOGIN_REQUIRED flag, which indicates that no
login must be performed and therefore no pin is necessary.
2. By setting the CKF_PROTECTED_AUTHENTICATION_PATH flag which
indicates that the PIN is provided outside of the PKCS#11 library.
See the PKCS#11 3.0 standard for the details [1].

Looking into the code of ssh-add, it was found that with the -s
argument, it asks for a PIN regardless of the PKCS#11 flags.
In [2] it just checks if the add flag is set, which is the case if
neither -e nor -d is provided.

Looking into the code of ssh to understand the behavior of ssh -I
revealed, that it considers the presence of the PKCS#11 flags (at least
partly).
If the CKF_LOGIN_REQUIRED flag is not set, as done by our HSM PKCS#11
library, SSH derives the keys available through the PKCS#11 library as
follows.
1. pkcs11_add_provider [3][4] is called, which calls
pkcs11_register_provider [5] 
2. pkcs11_register_provider performs some sanity checks and setting up,
and then tries to derive keys for the slots available [6]
3. For deriving keys a PKCS#11 session is opened by calling
pkcs11_open_session [7]. pkcs11_open_session checks if the
CKF_LOGIN_REQUIRED flag is set [8] and fails if it is set but no PIN
was provided.
4. After establishing a session pkcs11_fetch_keys is called [9], to
derive keys
5. If it was not possible to derive at least one key and no login took
place yet and the session is interactive, pkcs11_login_slot [10] is
called to perform a login.
   pkcs11_login_slot checks for the CKF_PROTECTED_AUTHENTICATION_PATH
flag [11] and allows the PIN entry to happen outside the PKCS#11
library.
   If the login was successful, pkcs11_fetch_keys is called again to
derive keys.


With these findings, the following questions arises.
- Did I miss a way to login via ssh, besides ssh -I and
ssh-agent/ssh-add -s, using a key provided by a PKCS#11 library?
- Are there any plans to adjust the behavior of ssh-add -s regarding
PKCS#11 PIN prompts to the one of ssh -I?
- Shouldn't ssh check for the CFK_LOGIN_REQUIRED flag, before trying to
login & deriving keys in step 5., if no keys were derived without
login?
- Would it be a possibility to, besides checking the PKCS#11 flags,
introduce an CLI argument that skips the interactive PKCS#11 PIN
entrance at all? 
  I could imagine that some PKCS#11 libraries get the login data
elsewhere but may not set the flags accordingly.

Thanks in advance!

Quirin


[1]
https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/os/pkcs11-base-v3.0-os.html
[2]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-add.c#L453
[3]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh.c#L2303
[4]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1672
[5]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1511
[6]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1598
[7]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1622 
[8]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L660
[9]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1625
[10]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1633
[11]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L260

-- 
You are receiving this mail because:
You are watching the assignee of the bug.