PKCS#11 support for openssh

[Alon Bar-Lev]

Damien Miller wrote:
> On Tue, 1 Nov 2005, Alon Bar-Lev wrote:
> 
> I am busy at the moment, hopefully I will have time to look at it 
> properly next week. Looking at it briefly, I was concerned about the 
> assumption of X.509 support - we have no intention of including x.509 at 
> present.
> 
> -d
> 

Thanks!
It is good to know that it is somewhere in the queue...

I want to explain why I think that X.509 is related to 
smartcard support... And then I will wait until you have 
some free time... :)

But first, I must say that I don't want to offend anyone... 
and I am sorry if you already know that, or you think I am 
talking none-sense.

I think your current approach is good for small systems or 
individuals... But it does not scale. And worse When your 
standard interface is raw keys on files, you create a false 
sense of security, since you have a record of a security 
product... And most people do not know better.

Let's say that the user knows that his key was stolen, now 
he has to create a list of every system that trusted his 
stolen key and remove the trust. During this phase, the user 
will most likely forget a few systems, that left vulnerable.

Most users will not report that their key was stolen and 
continue using it... The effort to update a new key in all 
the systems is too big. So every remote system is left 
vulnerable.

On enterprises, managing raw keys that are distributed all 
over with people come and go is very difficult, people that 
leave the enterprise will most likely be able to continue 
using their keys afterwards for a long period.

But there is an advantage... The user can backup his keys... 
So he can recover his keys from the last backup. So the user 
never loses his keys and can access his remote systems and 
modify their trust if he wishes by him-self.

Now... when user chooses to use smartcard, I assume he does 
this because it is more secure... and not because it is a 
neat device... :)

The environment should support this smartcard user. 
Smartcard keys cannot be backed up... So if the user 
lose/locks/damaged his card he also loses his keys. Since he 
does not have his key, he cannot generate a new key and 
modify the trust of remote systems by him-self... He need to 
contact the administrator of each remote system and ask him 
to update the trust, his situation is worse, since he has no 
way to prove his identity to the administrators, because he 
lost his keys...

Until all the administrators responses the remote systems 
are vulnerable... But my claim is that there are few systems 
that the user forgets...

Again... If the user uses smartcard because he want to 
enhance security, the last requirement would be to revoke 
his last identity from *ALL* remote systems. X.509 provides 
this service.

Lastly, the user will most likely use his smartcard for 
another purposes... Such as smartcard logon, email signing, 
SSL authentication... All which are X.509... (Except of 
gpg... where I had BIG failure...)

In order to summarize my argument:
1. X.509 is needed since smartcard user cannot backup his 
keys, every change of smartcard result in remote system 
update for *ALL* systems. The management overhead is huge. 
When using X.509 the user enrolls a new certificate using a 
different key, and then can access all remote systems 
without any remote change.
2. X.509 is needed in order to revoke old identities, thus 
not allowing ghost identities to exist on remote systems. It 
completes the security requirements when moving from 
software based storage to smartcards.
3. People who use PKCS#11 most likely uses it in X.509 
environment and they wishes to use the same identities also 
with openssh.

And on one sentence... If a user (on large scale) come to a 
conclusion that he wishes to use secure environment, he most 
likely use smartcard (PKCS#11) and X.509, drooping each will 
result in a security weakness.

On small scale, most users will not bother to use 
smartcards... and if they do... you can leave the opensc 
interface for them...

After said that...
I can modify my implementation to not using X.509 from 
openssh point of view, but I will still require X.509 
certificate and private key on token... I will also issue a 
patch for X.509 in order to use the certificate.

Regardless, I think that you should reconsider the X.509 
support issue.

Just to make my-self clearer... I don't think that current 
implementation of X.509 is complete... There are few issues 
to solve... But I think that we can all take openssh one 
step further, and adjust it for todays requirements.

Best Regards,
Alon Bar-Lev.