Re: [Opensc-devel] Understanding of ssh pkcs key provider

[Douglas E E. <dee...@gm...>]

On 5/23/2016 3:11 AM, Jakub Jelen wrote:
> On 05/21/2016 04:09 PM, Douglas E Engert wrote:
>> Looking at the https://github.com/openssh/openssh-portable/blob/master/ssh-pkcs11.c
>> in pkcs11_rsa_private_encrypt is where it is failing. All of the pkcs#11 code does not assume
>> that a card may be removed. It might be easy to fix if the same card is inserted, but not
>> if a different card is inserted.
>>
>> Seeing the SPY trace would help a lot. (note that your PIN may be exposed in the trace).
>>
>> Most of the initial information about the card is obtained when ssh-add sends the message to ssh-agent
>> to register a new provider. But it may be some time before that is actually used from pkcs11_rsa_private_encrypt.
>> In pkcs11_rsa_private_encrypt:
>>    if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
>> is checking if the user should be logged_in from the last use of when the provider was first added to ssh_agent.
>> The C_Sign operation also uses si->session which may not be valid especially if a different card was inserted.
>>
>> I don't know if you are willing to make code changes or not, or to push the issue with OpenSSH.


> OpenSSH pkcs11 currently does not support EC keys and needs a lot of
> changes to support them. There are at least two patches hanging around
> openssh mailing lists and bugzillas adding this support to some extent.
> I plan to have a look into this in the months or so to get that upstream.

Yes, EC support is a separate issue which should be addressed.

>
> To the actual topic, if you think this is a valid use case (reinsertion
> of the card), I can pick that up and try to implement a fix. But I would
> need a bit help in the case "how to look for a reinsertion of the card"
> as mentioned in previous mails.


PKCS#11 can return CKR_DEVICE_REMOVED to indicate the card had been removed. From an opensc SPY trace
of ssh_agent:

55: C_Sign
2016-05-22 09:14:41.715
[in] hSession = 0x7fe7fb518580
[in] pData[ulDataLen] <REDACTED>
Returned:  50 CKR_DEVICE_REMOVED

Problem is this card status change is only returned to calling application when some attempt is made
to contact the card.  The way the ssh-agent code is written, where certificates and keys are found
when ssh-add registers the provider, but the key may not be used until a C_Sign is needed may be
minutes or hours later, and the user may have pulled his card/ID badge out when leaving the workstation
then inserted it upon return.
C_WaitForSlotEvent and C_getTokenInfo could be used to detect if the card status has changed before
doing the C_Sign.

Many PKCS#11 implementations will invalidate any sessions and release objects when the card is removed.

Insertion of the same card will also require C_Login to be done again. Even without removal and insertion
use of the card by other applications could also cause the PIN to be required again.

>
> The problem from my point of view is that you have a terminal/keyboard
> when you add the key (ssh-add, message adding a card to the agent
> already contains pin), but when you do the signature, you don't have it
> and you have basically no way to get the PIN from the user (unless you
> would store it in the ssh-agent, which is generally not a good idea;
> message to sign from ssh does not have any field to provide PIN).

Caching of the PIN is an option and OpenSC has optional pin caching.(Other PKCS#11 libs may not) But the removal of the card
will cause the opensc cache, slots, sessions and objects to be cleared. And a different card might be inserted requiring a different PIN!

The use of a PIN PAD reader is another option especially in a high security environment, and I see ssh-pkcs11.c supports
CKF_PROTECTED_AUTHENTICATION_PATH, so PIN is never in the host but user has access to pin pad reader even from ssh-agent but has to *look* at the pin pad reader.

But the issue of PKCS#11 slots, sessions and objects need to be reestablished would still need to be addressed.

So would a better way to address this would be scripts run from screen unlock or some user
started background process to do a new ssh-add -s?
i.e. when user pulls the card, they are most likely going to leave workstation, or don't want
the card being used for some reason.

Smart cards introduce a lot of human factors which are not often considered when writing code.



>
> Regards,
>

-- 

  Douglas E. Engert  <DEE...@gm...>