openssh bugs - Jul 2015 - [Bug 2432] New: ssh-keygen and tools should be able to get public part directly from private key (portability)

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

            Bug ID: 2432
           Summary: ssh-keygen and tools should be able to get public part
                    directly from private key (portability)
           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

After testing and discussion with Nikos about Smart cards, and after
finding out that opencryptoki-swtok doesn't even store PUBLIC_KEY on
the card which makes it unusable with openssh (sending public key in
first step) I think we should be able to handle this also different
way.

Some tools are yet working this feature of ssh around by creating
self-signed certificates [1]. Before openssh-7 release, it seems to me
like great time to rethink smart cards handling. The thing is that even
if you don't have public key object on the card, you are able to
reconstruct public key from private key (p11tool example):

$ p11tool --login --export-pubkey
--provider=/usr/lib64/pkcs11/libopencryptoki.so
"pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=test;id=%92%44%ea%d2%18%12%c2%91%64%52%40%a2%83%99%07%7b%29%50%74%71;object=test2;type=private"
Enter PIN: 
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhCyiE9NGksjVLWfG//Zj
PO8mYDtc9G/t5OUNcmcJlXLTWfPzWXWJNmTZXV62x8qjEK/3ySMfzyQWyEKP4qgH
vHTeELgLFoookHWs3cckiKAZICdqlJMukJS440SzQKOs+2+SzaqkhdxjIIz5RNCe
B+ANIfM7gK/t4ERTE96aWmJQyD1utkfVkb43tjHbCf+Zm8U3mX0q1lDGmu7rhiel
OM/BUFSYh46l22EDHyHQayuvbcHtCQpAnfD94cUjvfLrNuv6EuriNl7TN3NAKb8p
/AWjl+IEl8g7Nlya9mV4Re0JVIZ+FFtJdDZMrYbaClTRnJweNV5JnHaT89Yrjjmw
NQIDAQAB
-----END PUBLIC KEY-----

This is example from opencryptoki, where it works well with swtoken and
I don't see any problem with this approach using yubikey. Also other
cards should be able to export public information from private key.

This is done using method C_GetAttributeValue with template:
CKA_MODULUS, CKA_PUBLIC_EXPONENT

The only drawback is that you need unconditionally log in to access
these fields, which is usability issue only for ssh-keygen tool -- you
are entering pin for ssh-add both ssh when connecting to remote server,
but it would be required to preserve session in ssh connect between
both stages (I'm not sure how much pain this would cause).

Still thinking about compatibility. Nikos says that this approach
should be possible to take with all the cards. There is problem in all
the tools if there is not public key.
Possibility will be to use this only as fallback option when there will
be no PK available. Or more radical change to use this as default and
fallback to public keys? Both would probably make more sense than
creating login options for ssh, ssh-add, ssh-keygen as we started
discussing in bug #2430.

I will have a look into codebase later. I just wanted to put everything
in together and then I can have a look at all the technical challenges,
since this will not be one-liner.

[1]
https://developers.yubico.com/yubico-piv-tool/SSH_with_PIV_and_PKCS11.html

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

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

--- Comment #1 from Jakub Jelen <jjelen at redhat.com> ---
Created attachment 2677
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2677&action=edit
read public part from private key in (not only in ssh-keygen).

First approach for reading private keys doesn't look too much painful. 


As I stated before, we need to have interactive login in ssh-keygen,
which is the first part of the patch.

Second thing is that I extracted interactive prompt for PIN from
pkcs11_rsa_private_encrypt into its own function pkcs11_do_login.

I use this function in pkcs11_open_session if I don't have pin provided
and the pkcs11 session is interactive. The failure is not fatal, since
in many cases you can proceed also without login.

The last thing is the filter itself, where I added filter for
CKA_PRIVATE_KEY. with according attributes. The rest is handled by
existing code since attributes are the same as for public keys.


Future possible improvement or modification can be the switch in
ssh-keygen that would force this interactive login (by default would be
0) to make the user experience the same:
+       pkcs11_init(force_login);

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

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

Damien Miller <djm at mindrot.org> changed:

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

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

I think with the recent changes, we might only need to query the
CKO_PRIVATE_KEY object class.

I don't have any way of testing this unfortunately.

-- 
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=2432

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=2432

Jakub Jelen <jjelen at redhat.com> changed:

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

--- Comment #3 from Jakub Jelen <jjelen at redhat.com> ---
After the years, I do no longer thing this is a very useful thing to
do. This would work nicely with RSA keys, but not with ECDSA, where the
public part is not always available in the private key object.
Additionally the need to login for most of the private keys makes its
use more complicated.

Moreover, all the sane smart cards have at least the public and private
keys available. Having only private ones I would consider a
misconfiguration. I am sorry for the confusion.

-- 
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=2432

Damien Miller <djm at mindrot.org> changed:

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

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

-- 
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.