PKCS#11 forwarding driver?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

PKCS#11 forwarding driver?

Ph. Marek
Hello everbody!

I seem to remember having read about a pkcs#11 forwarding driver, which allows
to forward pkcs#11 calls eg. over a network - to use any pkcs#11 aware
application (eg. firefox) with a smartcard being connected to another system.

Is that just a dream or does such a beast exist?


Thank you for all answers/pointers!


Regards,

Phil
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Cornelius Kölbel
Wow,
you would have to implement any kind of client server protocol, that is
not part of pkcs11.
Hm, such a thing sound very interesting...
regards
Cornelius

Ph. Marek schrieb:

> Hello everbody!
>
> I seem to remember having read about a pkcs#11 forwarding driver, which allows
> to forward pkcs#11 calls eg. over a network - to use any pkcs#11 aware
> application (eg. firefox) with a smartcard being connected to another system.
>
> Is that just a dream or does such a beast exist?
>
>
> Thank you for all answers/pointers!
>
>
> Regards,
>
> Phil
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>  

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Alon Bar-Lev
In reply to this post by Ph. Marek
On 5/8/07, Ph. Marek <[hidden email]> wrote:
> Hello everbody!
>
> I seem to remember having read about a pkcs#11 forwarding driver, which allows
> to forward pkcs#11 calls eg. over a network - to use any pkcs#11 aware
> application (eg. firefox) with a smartcard being connected to another system.
>
> Is that just a dream or does such a beast exist?

No.
But I am planning to implement such.

Alon.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Ph. Marek
Hello Alon!

On Dienstag, 8. Mai 2007, Alon Bar-Lev wrote:

> On 5/8/07, Ph. Marek <[hidden email]> wrote:
> > I seem to remember having read about a pkcs#11 forwarding driver, which
> > allows to forward pkcs#11 calls eg. over a network - to use any pkcs#11
> > aware application (eg. firefox) with a smartcard being connected to
> > another system.
> >
> > Is that just a dream or does such a beast exist?
>
> No.
> But I am planning to implement such.
That would be very good! If there's something I can help you with (eg.
testing), just ask -- I'll try to reserve some time for you.

Do you have any implementation concepts/ideas? Or do you want start them here?


Regards,

Phil
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Alon Bar-Lev
On 5/9/07, Ph. Marek <[hidden email]> wrote:
> That would be very good! If there's something I can help you with (eg.
> testing), just ask -- I'll try to reserve some time for you.

That's great!

> Do you have any implementation concepts/ideas? Or do you want start them here?

Yes... Some thoughts:

1. The daemon will expose PKCS#11 interface as protected
authentication path, so that applications will not require to set PIN.
This will allow PKCS#11 single sign-on throughout several
applications.

2. Minimal and secure client side implementation, so that the client
will not cause security issues in client process.

3. Implement (1) using unix sockets.

4. Have an option to work using TCP/TLS, have now idea how to
authenticate client to server yet.

5. Allow the server to load several providers, but still expose them
as one provider to the client, this will allow applications that
support only one provider to work with more than one provider.

This will be implemented as different slot names.

6. Haven't thoughts about slot events yet, don't know if I want to
support these in first version.

Alon.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Peter Stuge
On Wed, May 09, 2007 at 10:33:20PM +0300, Alon Bar-Lev wrote:
> 6. Haven't thoughts about slot events yet, don't know if I want to
> support these in first version.

I think it is important to do so. Better if it takes a bit longer to
be released.

Otherwise too many will use the version without.

Also, perhaps the system can be designed from the beginning to really
handle events well, in that case it will only be natural to implement
them.

Thanks for the effort!

An ssh-agent proxy on top of this would be neat. :)


//Peter
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Alon Bar-Lev
On 5/9/07, Peter Stuge <[hidden email]> wrote:
> On Wed, May 09, 2007 at 10:33:20PM +0300, Alon Bar-Lev wrote:
> > 6. Haven't thoughts about slot events yet, don't know if I want to
> > support these in first version.
>
> I think it is important to do so. Better if it takes a bit longer to
> be released.

Applications should fall-down to polling. So this should not be a problem.

> An ssh-agent proxy on top of this would be neat. :)

http://alon.barlev.googlepages.com/openssh-pkcs11

Best Regards,
Alon Bar-Lev.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Peter Stuge
On Wed, May 09, 2007 at 10:53:04PM +0300, Alon Bar-Lev wrote:
> > > 6. Haven't thoughts about slot events yet, don't know if I want
> > > to support these in first version.
> >
> > I think it is important to do so. Better if it takes a bit longer
> > to be released.
>
> Applications should fall-down to polling. So this should not be a
> problem.

Assume that "should" means it will be ignored. :p


> > An ssh-agent proxy on top of this would be neat. :)
>
> http://alon.barlev.googlepages.com/openssh-pkcs11

Yes, but that's not what I had in mind.

SSH already secures and forwards ssh-agent communication. It would be
more practical and possibly also more secure to have a proxy that
looks like an ssh-agent but uses the pkcs11net client to reach the
keystore.


//Peter
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Alon Bar-Lev
On 5/9/07, Peter Stuge <[hidden email]> wrote:
> > http://alon.barlev.googlepages.com/openssh-pkcs11
>
> Yes, but that's not what I had in mind.
>
> SSH already secures and forwards ssh-agent communication. It would be
> more practical and possibly also more secure to have a proxy that
> looks like an ssh-agent but uses the pkcs11net client to reach the
> keystore.

What is the difference between implementing properietary proxy
interface, and allowing openssh to use standard PKCS#11 interface?
The result is the same, only the later is standard.

Alon.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Ph. Marek
In reply to this post by Alon Bar-Lev
Hello Alon!

On Mittwoch, 9. Mai 2007, Alon Bar-Lev wrote:

> Yes... Some thoughts:
>
> 1. The daemon will expose PKCS#11 interface as protected
> authentication path, so that applications will not require to set PIN.
> This will allow PKCS#11 single sign-on throughout several
> applications.
>
> 2. Minimal and secure client side implementation, so that the client
> will not cause security issues in client process.
>
> 3. Implement (1) using unix sockets.
>
> 4. Have an option to work using TCP/TLS, have now idea how to
> authenticate client to server yet.
>
> 5. Allow the server to load several providers, but still expose them
> as one provider to the client, this will allow applications that
> support only one provider to work with more than one provider.
>
> This will be implemented as different slot names.
>
> 6. Haven't thoughts about slot events yet, don't know if I want to
> support these in first version.

Well, your thoughts are obviously much more detailed than mine ...
My points - which are more or less just brainstorming - :


7) The "server" should be implemented as a shared library, so that it can be
applied to any running process that opens a pkcs#11 session (see your SSO in
point 1).
I'd imagine some interface like
    int makeThreadAndConnect(int connection, CK_FUNCTION_LIST *list);
which creates a new thread, receives and sends messages on the given
connection, using the given PKCS#11 functions.
Although we might need to split that interface into something like
   int blob2functioncall(CK_FUNCTION_LIST *list,
           char *indata, int in_len, int *in_used_len,
           char *outdata, int out_len, int *out_used_len);
so that ssl_* functions may be used.

in_used_len would be used in this example for "pipelining" - if that makes
sense at all?? Most probably not.
The different fields in the blob can be asn.1 encoded ... but how do we signal
an end-of-message? TCP is a "stream", without block-boundaries ...


8) Cross-plattform. I'd surely need win32/linux server/client.
That should be no problem - we just have to en/decode the various data into
packets and back.

8a) For win32 named pipes instead of unix sockets would be needed, I think.


Does any of that make sense?


Regards,

Phil
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Peter Stuge
In reply to this post by Alon Bar-Lev
On Thu, May 10, 2007 at 07:33:21AM +0300, Alon Bar-Lev wrote:
> > It would be more practical and possibly also more secure to have
> > a proxy that looks like an ssh-agent
>
> What is the difference between implementing properietary proxy
> interface, and allowing openssh to use standard PKCS#11 interface?
> The result is the same, only the later is standard.

This depends on the definition of standard.

Secure shell is also a standard. The SSH agent protocol too.

But what really matters is that the SSH agent protocol is already
implemented everywhere.

Requiring PKCS#11 in ssh to be able to use p11net would be rather
useless in the short term (because it would not be widely available)
while providing an SSH agent proxy would make p11net useful
everywhere immediately! :)

Another option that works equally well is of course to teach
ssh-agent PKCS#11.


//Peter
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Alon Bar-Lev
On 5/10/07, Peter Stuge <[hidden email]> wrote:
> This depends on the definition of standard.
>
> Secure shell is also a standard. The SSH agent protocol too.

SSH is, SSH Agent protocol is specific to implementation.

> But what really matters is that the SSH agent protocol is already
> implemented everywhere.

Not at all!
This is how we got to none usable environment for users.
Please read:
http://alon.barlev.googlepages.com/open-source

We have an agent to ssh, an agnet to gnupg an agent for gnome, gnutls
wanted to add its own agent.
Every project out there think it is smarter than the other, create its
own interface, and call it a standard.
A standard is not only a document YOU agree of, it is a specification
that MANY partners agree of and for different usages.

In term of accessing cryptographic meterial we have two stanard:
1. CryptoAPI - standard by monopoly.
2. PKCS#11

You can say that PKCS#11 is too complex, badly designed, is an API and
not data specification, it missing key features, I will agree with
all. But at least it is available for developers and users to use.

If all application such as OpenSSL, GnuTLS, OpenVPN, OpenSSH, GnuPG,
KDE, Gnome, Mozilla etc... would have supported one interface, hence
PKCS#11, user will benafit from a secure environenment.

Now days, a user should run about 5 separate agents on its machine in
order to work with his smartcard. This is unacceptable.

> Requiring PKCS#11 in ssh to be able to use p11net would be rather
> useless in the short term (because it would not be widely available)
> while providing an SSH agent proxy would make p11net useful
> everywhere immediately! :)

I am looking into long term... Making open source developer to realize
that they need to conform to standard for users' sake.
I am doing most of the work, most projects happy to merge the
modifications, others such as OpenSSH and GnuPG are not.

GnuPG developers just don't like PKCS#11.
OpenSSH developers were interested at first, then disappeared.

I know that many users choose to use the PKCS#11 implementation of
these two, since it solves so much incompatibilities issues.

OpenVPN users are very happy that upstream was responsive.
I hope that KDE developers will be happy as well, if we can get
Konqueror use QCA in next version.

GnuTLS has work in progress, and I hope that the new API additions
will enbale PKCS#11 integration.

> Another option that works equally well is of course to teach
> ssh-agent PKCS#11.

This what I have done.

Best Regards,
Alon Bar-Lev.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Eddy Nigg (StartCom Ltd.)
Alon Bar-Lev wrote:
If all application such as OpenSSL, GnuTLS, OpenVPN, OpenSSH, GnuPG,
KDE, Gnome, Mozilla etc... would have supported one interface, hence
PKCS#11, user will benafit from a secure environenment.

Now days, a user should run about 5 separate agents on its machine in
order to work with his smartcard. This is unacceptable.

  
I must absolutely agree with your statement above! Just to let you know, that there are people listing to discussions and want to provide some feedback ;-)

--
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Jabber:      [hidden email]
Phone:       +1.213.341.0390

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Bud P. Bruegger
In reply to this post by Alon Bar-Lev
Hi Alon,

have you already made progress in the implementation?  I was very
interested in this since I'd like to write some non-traditional pkcs#11
module and I'd prefer to do that in python...  I was wondering whether
the forwarding driver could be a good fit for this...

In more detail, instead of using a static, local token, I would like to
interface the pkcs#11 to a dynamic certificate:  the middleware first
creates a keypair, sends it off to a CA that issues a certificate on
the fly, and then presents that through the pkcs#11 interface.  

Will this kind of thing be possible?

many thanks in advance

-bud
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Alon Bar-Lev
On 7/2/07, Bud P. Bruegger <[hidden email]> wrote:
> Hi Alon,
>
> have you already made progress in the implementation?  I was very
> interested in this since I'd like to write some non-traditional pkcs#11
> module and I'd prefer to do that in python...  I was wondering whether
> the forwarding driver could be a good fit for this...

No, I had no time yet.
But now, after KDE guys deferred smartcard integration in a year, I
probably have some time.

> In more detail, instead of using a static, local token, I would like to
> interface the pkcs#11 to a dynamic certificate:  the middleware first
> creates a keypair, sends it off to a CA that issues a certificate on
> the fly, and then presents that through the pkcs#11 interface.
>
> Will this kind of thing be possible?

I don't think so.
There is no valid common sequence that will allow you to do this.
I also don't see the use case, can you please explain?

Alon.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Jim Rees
Alon Bar-Lev wrote:

  > In more detail, instead of using a static, local token, I would like to
  > interface the pkcs#11 to a dynamic certificate:  the middleware first
  > creates a keypair, sends it off to a CA that issues a certificate on
  > the fly, and then presents that through the pkcs#11 interface.
  >
  > Will this kind of thing be possible?
 
  I don't think so.
  There is no valid common sequence that will allow you to do this.
  I also don't see the use case, can you please explain?

We do something like this to translate kerberos tickets into cert/key usable
from pkcs11.  But it only makes sense if you have some way to convince the
CA that it should sign the keypair and issue a cert.  In our case that's
kerberos.  Otherwise, how can anyone trust the cert?
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Alon Bar-Lev
On 7/2/07, Jim Rees <[hidden email]> wrote:
> We do something like this to translate kerberos tickets into cert/key usable
> from pkcs11.  But it only makes sense if you have some way to convince the
> CA that it should sign the keypair and issue a cert.  In our case that's
> kerberos.  Otherwise, how can anyone trust the cert?

But Kerberos is weaker than PKI in term of authentication.
You can use PKI in order to authenticate to Kerberos.
So you have static certificate for user and dynamic authorization
using kerberos.

Alon.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Miller, Timothy J.
There is no getting around the enrollment trust problem.  Most  
sensible smartcard and PKI deployments handle this via an enrollment  
ceremony that involves a face-to-face component.

-- TIm

On Jul 2, 2007, at 1:59 PM, Alon Bar-Lev wrote:

> On 7/2/07, Jim Rees <[hidden email]> wrote:
>> We do something like this to translate kerberos tickets into cert/
>> key usable
>> from pkcs11.  But it only makes sense if you have some way to  
>> convince the
>> CA that it should sign the keypair and issue a cert.  In our case  
>> that's
>> kerberos.  Otherwise, how can anyone trust the cert?
>
> But Kerberos is weaker than PKI in term of authentication.
> You can use PKI in order to authenticate to Kerberos.
> So you have static certificate for user and dynamic authorization
> using kerberos.
>
> Alon.
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Tarasov Viktor
Timothy J. Miller a écrit :
> There is no getting around the enrollment trust problem.  Most
> sensible smartcard and PKI deployments handle this via an enrollment
> ceremony that involves a face-to-face component.
As for enrollment trust problem, IMHO, using the secure channel is good
alternative to the face-to-face .
From the technical point of view, a distant enrollment with secure
channel can be more secure
then face-to-face enrollment without secure channel .

Regards,
Viktor.



>
> -- TIm
>
> On Jul 2, 2007, at 1:59 PM, Alon Bar-Lev wrote:
>
>> On 7/2/07, Jim Rees <[hidden email]> wrote:
>>> We do something like this to translate kerberos tickets into
>>> cert/key usable
>>> from pkcs11.  But it only makes sense if you have some way to
>>> convince the
>>> CA that it should sign the keypair and issue a cert.  In our case
>>> that's
>>> kerberos.  Otherwise, how can anyone trust the cert?
>>
>> But Kerberos is weaker than PKI in term of authentication.
>> You can use PKI in order to authenticate to Kerberos.
>> So you have static certificate for user and dynamic authorization
>> using kerberos.
>>
>> Alon.
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 forwarding driver?

Ph. Marek
In reply to this post by Ph. Marek
Hello Alon!

Another idea I just had ...
If the forwarding driver supports serializing the PKCS#11-commands, how about
spooling them into some file, and replaying them somewhere else? This would
allow disconnected smartcard initialization.


Regards,

Phil
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
12