openssh bugs - Jul 2015 - [Bug 2430] New: ssh-keygen should allow to login before reading public key from smart card

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

            Bug ID: 2430
           Summary: ssh-keygen should allow to login before reading public
                    key from smart card
           Product: Portable OpenSSH
           Version: 6.9p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Smartcard
          Assignee: unassigned-bugs at mindrot.org
          Reporter: jjelen at redhat.com

Based on our investigation of Smart Cart usability with openSSH we
found several minor problems that were filled in our red hat bugzilla
[1]. Next is problem again with softHSM. It is hiding by default both
public and private key, until you login to the card. This is not rare
feature and it is useful, because it hides all the data on the card for
unauthorized access.

Most of the pkcs11 tools have ability to do login before doing
operation with card. Openssh does it now only for the operation that
are generally expected to require PIN. Doing so would probably require
another switch for ssh-keygen, which is not much convenient (and there
is not much letters left for keygen).

The other possibility would be to fallback to login, if keygen will not
find any keys without login -- this would be more transparent for
users, but would possibly hide some keys if there would be at least one
readable before login.

I am not yet providing a patch here, since this issue would require
consideration which way to take. It would be great to start discussion
about pros and cons of both solutions or to come up with different
solution.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1241873

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Wouldn't all the tools that use PKCS#11 need an additional switch? I.e.
ssh and ssh-add in addition to ssh-keygen.

Is this behaviour common in real tokens? My experience is quite
limited, but I've not seen tokens refuse to provide at least the public
key or cert without login.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #2 from Jakub Jelen <jjelen at redhat.com> ---
Yes. ssh-add would require same change. I forgot.

I didn't get so far with ssh. But it does Login, because it requires to
unlock the private key to sign challenge. I'm not familiar with the
pkcs11 code in ssh yet, but I don't think it opens session twice, once
for public key and then for signing challenge.
> Is this behaviour common in real tokens?
I was told that it is not uncommon, but I also don't have experience
about this. I will ask collegue if he can estimate or provide some
examples.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #3 from Jakub Jelen <jjelen at redhat.com> ---
These cards exists for example as National IDs (example Belgium from
colleague's experience [1]). Unfortunately, wiki does not explicitly
mention mechanism of handling public key. But it can be found for
example in this article [2].

It is often enforced as a policy by generator/distributor of the cards
rather then by user, in nation-wide or corporate scenarios.

Solution with switch would be probably more familiar, but it would be
great to have one switch, unlike it differs with switches shared pkcs11
library:
ssh -I *.so
ssh-keygen -D *.so
ssh-add -s *.so

I can think of -U as "Unlock", which is unused on all three of them.
Handling this inside ssh tools would reqeuire some design decisions how
to make it clear, secure and transparent even for readers keypads.

[1] https://en.wikipedia.org/wiki/Electronic_identity_card#Belgium
[2] http://wiki.yobi.be/wiki/Belgian_eID#pkcs11-tool

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #4 from Jakub Jelen <jjelen at redhat.com> ---
This issue could be resolved by the PKCS#11 URIs (bug #2817), which
allow the specify the PIN or PIN source (not yet implemented in the
referenced bug), which might be a hint for the tool to perform Login
before trying to list objects.

But over the recent years, I did not see almost any cards that would
have this issue so I don't think this is very important now.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #5 from Jakub Jelen <jjelen at redhat.com> ---
Created attachment 3130
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3130&action=edit
Try to login, if the first attempt does not return any keys

After discussion in bug #2652, we have a real use case as I proposed
over two years ago and therefore we need to figure out how to solve
this problem (in the #2652 complicated by the use of "pinpad" reader
keyboard).

The initial proposal of introducing a new command line option to both
ssh-keygen and ssh seems too intrusive. The ssh-add does NOT need any
modification, because it already does the login while adding a card (it
is the only time when agent has a PIN). It can be simply verified with
the following reproducer with softhsm2:

$ SOPIN="12345678"
$ echo "directories.tokendir = .tokens/" > .softhsm2.conf
$ mkdir ".tokens"
$ export SOFTHSM2_CONF=".softhsm2.conf"
$ PIN="123456"
$ softhsm2-util --init-token --slot 0 --label "SC test"
--so-pin="$SOPIN" --pin="$PIN"
$ P11LIB="/usr/lib64/pkcs11/libsofthsm2.so"
$ pkcs11-tool --keypairgen --key-type=RSA:2048 --login --pin=$PIN
--module="$P11LIB" --label="test" --id=01 --private
$ pkcs11-tool -O --module=$P11LIB
<<< does not list any objects
$ pkcs11-tool -O --module=$P11LIB --pin=$PIN
<<< lists objects
$ eval `ssh-agent`
$ ssh-add -s /usr/lib64/pkcs11/libsofthsm2.so
$ ssh-add -l
<<< lists the added keys


What needs to be fixed are the ssh and ssh-keygen. As we see, the most
common configurations are cards which have either all the public
objects visible or none of them. The simplest solution that might be
needed for the applications is to try to login, if a card returns zero
keys without it.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Peter Magnusson <peter.sj.magnusson at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.sj.magnusson at gmail.co
                   |                            |m

--- Comment #6 from Peter Magnusson <peter.sj.magnusson at gmail.com> ---
Created attachment 3133
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3133&action=edit
Similar patch created while getting yubihsm_pkcs11.so to work with
openssh

Duplicate work, didn't realize this was allready worked on while
debugging yubihsm support. Provided for reference if anything in my
version is of interrest to incorporate.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2988


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2988
[Bug 2988] Tracking bug for 8.1 release
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
Shouldn't token that refuse to show pubkeys without login assert
CKF_LOGIN_REQUIRED? We already have code that attempts to deal with
that (though there are apparently some problems there).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pkcs11

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
Created attachment 3279
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3279&action=edit
revised diff

Maybe something like this could be used to attempt login if no keys
were found. I'm not sure about the heuristic for activating it though,
as soon as it finds any key it will skip later attempts a login and so
would fail to find keys on tokens that mix login-required and not.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #9 from Jakub Jelen <jjelen at redhat.com> ---
This looks reasonable and somehow follows what I was initially
proposing.

Tested with my patch (Regression) from mailing list (filled as a new
bug #3006) and with reproducer in comment #5 and with real card.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Damien Miller <djm at mindrot.org> ---
patch applied; will be in openssh-8.1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #11 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.