openssl engine loading in wpa_supplicant
j at w1.fi
Wed May 2 23:59:57 EDT 2007
On Tue, Apr 24, 2007 at 02:40:43PM -0700, Mattes, David wrote:
> I'm trying to perform EAP-TLS auth with an openssl engine interface to a
> smartcard. I think the engine initialization is taking long enough that
> the AP infrastructure is resetting the EAP-TLS state. When I watch an
> ethereal capture, the EAP transaction starts and then wants a Client
> Hello. When the client doesn't respond, the EAP re-initializes.
> Getting access to the infrastructure to tweak any timeout settings is
> most likely not an option.
Which authenticator and RADIUS server are you using?
> Any recommendations on how to get the engine to pre-load before the
> EAP-TLS negotiation begins? Currently the engine loading and
> initialization is taking ~5 seconds!!!
Five seconds does not sound long enough time for a reasonable
authenticator to time out EAP-TLS authentication.. Anyway, the engine
itself is loaded only once at wpa_supplicant startup, i.e., before
EAP-TLS is even started.. I would assume you are seeing the time it
takes for the engine to initialize and select the private key from the
smart card when a new TLS connection is opened for EAP-TLS.
Could you please send debug log from wpa_supplicant with timestamps (add
-ddt on the command line)? This would help in figuring out what exactly
is taking so long.
It would be possible to move the private key selection to happen
earlier, but that does not fit in very well with the current network
configuration profile in wpa_supplicant. Easiest way of doing this could
be to move the tls_engine_init() initialization from per-connection to
global context to be done before TLS connections are initialized. There
is no mechanism for this in the current TLS API in wpa_supplicant, but
this could be supported by adding a new tls_preload_engine() function
that is called with the global TLS context for each configured network
that uses OpenSSL engine.
The new tls_preload_engine() would then initialize all configured
engines, i.e., engine_id,pin,key_id triples. These engines would be
stored in the global context and tls_connection_set_params() (or to be
more exact, tls_engine_init() and tls_connection_engine_private_key()
could then use the cached engine from the global context.
This kind of addition would allow the smartcard connection to be opened
at startup and then shared for all future calls. One drawback with this
is that the card would be reserved for this use even at times when it is
not strictly needed. Though, this could be acceptable for many use
I'm not very familiar with then OpenSSL engine implementation, so I
don't know whether it could cache some of the smartcard data to speed up
the initialization. This would be much nicer solution from the view
point of not having to modify wpa_supplicant with OpenSSL-specific
changes. The engine code could then use some kind of serial number from
the smartcard to recognize the card and use the cached data instead of
having to do all smartcard operations again.
Jouni Malinen PGP id EFC895FA
More information about the HostAP