wpa_supplicant in FIPS 140-2 mode

[Jouni Malinen]

On Wed, Jul 29, 2015 at 02:50:09PM -0400, Jate Sujjavanich wrote:
> I figured out an issue with the aes_wrap/aes_unwrap function calls causing
> the exit. The ones implemented in crypto_openssl.c make a lower level call
> which is not allowed in FIPS mode for 1.0.1. I will submit a patch which
> uses the more generic callbacks in src/crypto/aes_wrap.c and
> src/crypto/aes_unwrap.c.

Hmm.. That would be somewhat of an unfortunate direction.. My goal has
been more to reduce externally required crypto implementation than
adding it, i.e., this change would be reverting an earlier cleanup. It's
a bit unfortunate if OpenSSL does not provide a FIPS mode compatible
mechanism for AES key wrapping.

> Now I am looking into the OpenSSL FIPS error in the context of the
> following debug output:

> OpenSSL: EVP_DigestInit_ex failed: error:060A80A3:digital envelope
> routines:FIPS
> _DIGESTINIT:disabled for fips
> EAP: Received EAP-Request id=1 method=1 vendor=0 vendorMethod=0
> 
> In function eap_sm_parseEapReq in eap.c, the following call is triggering
> the OpenSSL error. It is approximately line 1769:
> 
>         ret = md5_vector(1, addr, &plen, sm->req_md5);

Ah.. For some reason, this one did not show up when I last looked at
CONFIG_FIPS=y (which was quite some time ago)..

> It appears that the eap_workaround setting tells wpa_supplicant to make the
> call to md5_vector. The wpa_supplicant is able to successfully
> authenticate. I can also set eap_workaround=0, and it still works with my
> networking equipment. In FIPS mode, I believe that this call does not do
> anything because OpenSSL in FIPS mode returns an error before doing
> anything.

This does not really need to use a strong hash, but I guess it would be
fine to change that workaround to use SHA256. In theory, that workaround
is not supposed to be needed at all, but well.. There are likely still
broken authentication server implementations, so will need to maintain
something to check whether frames are identical. With some more memory
use, this could also just maintain a copy of the previous message, but a
light weight hash value would be sufficient here.

-- 
Jouni Malinen                                            PGP id EFC895FA