| Message ID | CAPphmgYv+Am+6UZPGXWOQHmnc368rXBmg4+YZpOtiwKLG8H0Hw@mail.gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Wed, Jul 29, 2015 at 05:20:06PM -0400, Jate Sujjavanich wrote: > I replaced the calls within to aes_wrap/aes_unwrap in crypto_openssl.c with > the callbacks in aes_wrap.c/aes_unwrap.c. They actually lead down to EVP_* > functions within OpenSSL which is valid in FIPS mode. The callbacks to > aes_encrypt_* lead to higher level EVP_* calls which are allowed in FIPS > mode. > > Do you see anything wrong with this algorithmically as far as encryption is > concerned? No, the changes here are just reverting back to the older design. In fact, all you would have needed to do for this is "git revert f19c907822ad0dec3480b1435b615ae22c5533a1" (i.e., revert the "OpenSSL: Implement aes_wrap() and aes_unwrap()" commit).. Like I said, this is not the direction I want to go to, so I hope that there is a better solution for AES key wrap than this as far as hostap.git is concerned.
> > 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. > In this post on openssl-users - http://marc.info/?l=openssl-users&m=140075543711643&w=2 - one of the maintainers of OpenSSL provides an example of how to use the allowed higher level EVP_* calls to implement FIPS mode-compatible AES key wrapping. The code in the example very closely matches the code within aes-wrap.c and aes-unwrap.c. I suggested re-adding that code to avoid code duplication without realizing that it's a revert of f19c907 Would putting the aes_wrap and aes_unwrap calls from aes-[un]wrap.c into crypto_openssl.c work? - Jate S. On Thu, Jul 30, 2015 at 5:09 AM, Jouni Malinen <j@w1.fi> wrote: > On Wed, Jul 29, 2015 at 05:20:06PM -0400, Jate Sujjavanich wrote: > > I replaced the calls within to aes_wrap/aes_unwrap in crypto_openssl.c > with > > the callbacks in aes_wrap.c/aes_unwrap.c. They actually lead down to > EVP_* > > functions within OpenSSL which is valid in FIPS mode. The callbacks to > > aes_encrypt_* lead to higher level EVP_* calls which are allowed in FIPS > > mode. > > > > Do you see anything wrong with this algorithmically as far as encryption > is > > concerned? > > No, the changes here are just reverting back to the older design. In > fact, all you would have needed to do for this is "git revert > f19c907822ad0dec3480b1435b615ae22c5533a1" (i.e., revert the "OpenSSL: > Implement aes_wrap() and aes_unwrap()" commit).. Like I said, this is > not the direction I want to go to, so I hope that there is a better > solution for AES key wrap than this as far as hostap.git is concerned. > > -- > Jouni Malinen PGP id EFC895FA > _______________________________________________ > HostAP mailing list > HostAP@lists.shmoo.com > http://lists.shmoo.com/mailman/listinfo/hostap >
On Fri, Jul 31, 2015 at 03:16:24PM -0400, Jate Sujjavanich wrote: > In this post on openssl-users - > http://marc.info/?l=openssl-users&m=140075543711643&w=2 - one of the > maintainers of OpenSSL provides an example of how to use the allowed higher > level EVP_* calls to implement FIPS mode-compatible AES key wrapping. The > code in the example very closely matches the code within aes-wrap.c and > aes-unwrap.c. I suggested re-adding that code to avoid code duplication > without realizing that it's a revert of f19c907 > > Would putting the aes_wrap and aes_unwrap calls from aes-[un]wrap.c into > crypto_openssl.c work? I don't think it makes much of a difference where this functionality is as far as the source code files are concerned, so we may as well share the existing aes-{,un}wrap.c implementation. I have number of CONFIG_FIPS=y related regression fixes in the pending branch in hostap.git including a change that does this with a partial revert of f19c907 (i.e., revert it for the CONFIG_FIPS=y case only). I'm also replacing the MD5-based EAP workaround with SHA1 and removing MD5 completely from the build to force the issues to show up at build time rather than as failures during runtime. There are still number of older protocols that require MD5, so those must not be included in build configuration when CONFIG_FIPS=y is used. With those changes, it is now again possible to build wpa_supplicant for OpenSSL FIPS mode and complete WPA2-Enterprise connection with EAP-TLS.
diff --git a/src/crypto/crypto_openssl.c b/src/crypto/crypto_openssl.c index f158ef4..ca44386 100644 --- a/src/crypto/crypto_openssl.c +++ b/src/crypto/crypto_openssl.c @@ -297,33 +297,6 @@ void aes_decrypt_deinit(void *ctx) } -int aes_wrap(const u8 *kek, size_t kek_len, int n, const u8 *plain, u8 *cipher) -{ - AES_KEY actx; - int res; - - if (AES_set_encrypt_key(kek, kek_len << 3, &actx)) - return -1; - res = AES_wrap_key(&actx, NULL, cipher, plain, n * 8); - OPENSSL_cleanse(&actx, sizeof(actx)); - return res <= 0 ? -1 : 0; -} - - -int aes_unwrap(const u8 *kek, size_t kek_len, int n, const u8 *cipher, - u8 *plain) -{ - AES_KEY actx; - int res; - - if (AES_set_decrypt_key(kek, kek_len << 3, &actx)) - return -1; - res = AES_unwrap_key(&actx, NULL, plain, cipher, (n + 1) * 8); - OPENSSL_cleanse(&actx, sizeof(actx)); - return res <= 0 ? -1 : 0; -} - - int crypto_mod_exp(const u8 *base, size_t base_len, const u8 *power, size_t power_len, const u8 *modulus, size_t modulus_len, diff --git a/wpa_supplicant/Makefile b/wpa_supplicant/Makefile index 0f82af9..87af300 100644 --- a/wpa_supplicant/Makefile +++ b/wpa_supplicant/Makefile @@ -983,6 +983,10 @@ LIBS += -lssl endif OBJS += ../src/crypto/crypto_openssl.o OBJS_p += ../src/crypto/crypto_openssl.o +OBJS += ../src/crypto/aes-wrap.o +OBJS_p += ../src/crypto/aes-wrap.o +OBJS += ../src/crypto/aes-unwrap.o +OBJS_p += ../src/crypto/aes-unwrap.o ifdef NEED_FIPS186_2_PRF OBJS += ../src/crypto/fips_prf_openssl.o endif