Yes, I understand all that; we currently have our own certified FIPS module that I wired into OpenSSL via the engine APIs. Assuming that the module boundary is the code in the FIPS canister, I want that module to perform all FIPS-compliant operations, but still need the "outer" OpenSSL to perform other operations. For example, authentication with EAP-TTLS can use weaker inner authentication protected by the stronger outer tunnel. MS-CHAPv2, e.g. uses NT password hashing.
It seems the purpose of these NON_FIPS_ALLOW flags is for exactly this reason - that a developer can decide what is allowable for a FIPS-capable OpenSSL in FIPS mode based on the context of the actual crypto operations relative to what is required to be truly FIPS compliant. It just seems in this case that the implementation is not correct in order to allow this (the FIPS_cipherinit in fipscanister checks this flag, but the FIPS-capable implementation around it happens to clear the flag before it can be analyzed). .................................... Erik Tkal Juniper OAC/UAC/Pulse Development -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thor Lancelot Simon Sent: Friday, February 10, 2012 9:52 AM To: [email protected] Subject: Re: FIPS Module 2.0 -- using non-FIPS ciphers On Fri, Feb 10, 2012 at 09:39:20AM -0500, Erik Tkal wrote: > I am experimenting with the OpenSSL FIPS Module 2.0, but am encountering some > difficulty. > > > > I need to perform some RC4 calculations in code that does not need to be > FIPS compliant, even though I want all FIPS ciphers to be performed in > FIPS mode. You should talk to whoever wrote the security policy for your device or application. To do this without compromising your FIPS validation, you likely need to move the code in question -- the code that uses a non-FIPS cipher -- outside the "module boundary". It is probably a good rule of thumb that if symbols in the same instance of the OpenSSL library used within the boundary are visible to your code that is using a non-Approved algorithm, the code using the non-Approved algorithm is (improperly) within the module boundary. If you move the code outside the module boundary, you should be able to link it to a different copy of OpenSSL, and the problem should go away. I suppose you might be using RC4 to generate initialization vectors. I cannot remember whether that is allowed. If it is, you likely need a constrained, standalone RC4 implementation (which would only be about 10 lines of code) that you can prove to the test lab validating your device or application is actually never used (or not usable) for any purpose other than IV generation. If you are relying on OpenSSL's certificate in order to claim FIPS 140 compliance for your application or device, it is definitely improper to have other implementations of cryptographic algorithms floating around unless you can clearly establish (and advertise) that they are part of a separate application which is _not_ FIPS 140 compliant. Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
