Smartcards and wpa_supplicant
g.hecker at et.bocholt.fh-ge.de
Wed Mar 9 11:36:03 EST 2005
Jouni Malinen wrote:
> On Tue, Jan 25, 2005 at 11:11:32AM +0100, Gordon Hecker wrote:
>>First a short summary to get it all back to your mind:
>>The patch implements smartcard support for EAP-TLS in wpa_supplicant
>>using the Openssl Engine interface with the engines provided by the
>>Opensc project. So at least in theory every smartcard supported by
>>Opensc should be usable. I'm using a Cryptoflex Egate USB Token.
> Unfortunately, OpenSC does not seem to support PKCS#15 initialization
> for SetCOS and I happen to only have SetCOS cards. One of the cards is
> actually already initialized, but of course I don't remember PIN for
> it.. ;-) (nor do I have a private key that I could use in the
> authentication server).
> In other words, I don't currently have suitable hardware for testing the
> wpa_supplicant changes. I can try to find a source for supported cards
> at some point, but that may take some time. If you happen to know one,
> please let me know. I can also try to see if I could initialize the card
> with another tool since it is only the initialization part that is
> missing from OpenSC.
I'm using cryptoflex egate - but I must admit that I never tried to
order them myself. I only heard that it's not easy to get them.
Anyway - I'm initializing my smartcard in a way that it works in
combination with my usual environment. Certificates and authentication
>>As I said, it would be great if you could integrate the code in one of
>>the next wpa_supplicant releases.
> I can start merging changes into wpa_supplicant. PIN through wpa_cli is
> a good starting point, since it is needed for EAP-SIM/AKA, too. Rest of
> the changes should be doable, but like I said, I won't be able to test
> them completely.
I have extracted the PIN-through-wpa_cli related changes and created a
diff containing only those.
It's mostly copy'n'paste from the corresponding functionality
of the password command.
In wpa_cli.c there's a workaround to detect if there's an exact match
of a command - since the 'pin' command was rejected before because it is
ambiguous with the first three characters of the 'ping' command.
There's no code included that makes EAP-SIM or AKA use that
functionality. I don't want to mess around in that code for now.
So the patch on its own is pretty useless ;-)
But if you are fine with it you might start merging it.
> Couple of changes needs to be done to the patch, though, before it can
> be merged in. I went through the changes and here's list of comments:
I'm working through your comments on the other parts. Most of the things
are solved, I'll see how I can split the big patch into pieces and
resend them as soon as possible.
> + * tls_engine_load_dynamic_generic -
> + * This function is a generic function that loads any openssl engine.
> + * It's code is based upon an example found in the engine(3) manpage
> + * from openssl
> What license is used for that code? OpenSSL license is not compatible
> with the license used in wpa_supplicant as far as including code from
> OpenSSL to wpa_supplicant is concerned.
It's my own code, not a copy'n'paste. I just coded it after reading the
So licensing it under wpa_supplicant's license should be fine.
More information about the HostAP