Bug 2432

Summary: ssh-keygen and tools should be able to get public part directly from private key (portability)
Product: Portable OpenSSH Reporter: Jakub Jelen <jjelen>
Component: SmartcardAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED INVALID    
Severity: enhancement CC: djm
Priority: P5 Keywords: pkcs11
Version: 6.9p1   
Hardware: Other   
OS: Linux   
Attachments:
Description Flags
read public part from private key in (not only in ssh-keygen).
none
revised diff? none

Description Jakub Jelen 2015-07-20 23:33:34 AEST 
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
Comment 1 Jakub Jelen 2015-07-23 17:28:24 AEST 
Created attachment 2677 [details]
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);
Comment 2 Damien Miller 2019-05-10 13:48:06 AEST 
Created attachment 3278 [details]
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.
Comment 3 Jakub Jelen 2019-05-10 17:59:20 AEST 
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.
Comment 4 Damien Miller 2021-04-23 14:55:50 AEST 
closing resolved bugs as of 8.6p1 release