[PATCH] enhanced smartcard support

[David Smith]

2008/05/02 (Fri) 01:45:11 ? Dan Williams ????????:
> On Fri, 2008-05-02 at 01:36 +0900, David Smith wrote:
> > Hi all,
> >
> > I've attached three patches to extend the existing smartcard support to
> > handle client certificates and CA certificates as well as EAP-TLS phase2
> > auth. I've added the following ssid configuration variables to
> > wpasupplicant for this:
> >
> >  cert_id, ca_cert_id, key2_id, cert2_id, and ca_cert2_id
>
> Quick question; are these paths to certificate files, or some other
> token?

They are specified the same as the current "key_id" setting, as a PKCS#11 
object id. For example, in the TPM chip in my laptop accessed via 
opencryptoki pkcs#11, the cert and key for my companies wireless acess both 
have ID "4".

Consider this output:
# 
pkcs11-tool --module /usr/lib/opencryptoki/libopencryptoki.so --login --list-objects
Please enter User PIN:
Private Key Object; RSA
  label:      IPsec VPN RSA private key
  ID:         01
  Usage:      decrypt, sign, unwrap
Private Key Object; RSA
  label:      GPG System Sign key
  ID:         03
  Usage:      decrypt, sign, unwrap
Private Key Object; RSA
  label:      802.1x RSA private key
  ID:         04
  Usage:      decrypt, sign, unwrap
Certificate Object, type = X.509 cert
  label:      IPSec VPN x509 Certificate
  ID:         01
Certificate Object, type = X.509 cert
  label:      GPG System Sign cert
  ID:         03
Certificate Object, type = X.509 cert
  label:      802.1x x509 Certificate
  ID:         04

You can see that I have in my "smartcard" (in this case the TPM chip) a 
selection of RSA keys and certificates and I specify which one I will use for 
whatever purpose to wpasupplicant by the ID field.

I'm pretty confident this is how other people using smartcards will find it, 
as well, at least any of the usual smartcards supported by either 
opencryptoki or OpenSC.

> In many cases we don't want wpa_supplicant reading all around 
> the disk because it's a lot harder to confine the supplicant with things
> like SELinux if it just gets passed filenames.  That's one of the
> reasons why NetworkManager passes the actual binary data of the
> certificate to the supplicant instead of passing a path.

Yep, this should be equally efficient if not more so.

>
> > I'm looking for people to help test this. At the current time, it relies
> > on the LOAD_CERT_CTRL extension provided by the PKCS#11 OpenSSL engine
> > from the OpenSC project. If any other OpenSSL engines support a similar
> > extension, inform me and I'll support for them. But since the PKCS#11
> > engine is probably by far the most used one with wpasupplicant, I think
> > this is a good start.
> >
> > Again, this code should definitely be tested more before it is ready for
> > merging but please give it a read and a try.
> >
> > Cheers,
> > dds



-- 
man perl | tail -6 | head -2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20080502/07ff30dd/attachment-0001.pgp