Patrick Rael wrote:
Hello, I have 6 questions about making a host FIPS-140-2 compliant.
Belated responses below...
I was able to build both openssl-fips-1.2 and openssl-0.9.8j-dev
(stable snapshot) on FreeBSD6.3 and combine the canister files,
install on a server, and adjust ldconfig so apps use the new libs.
Now lsof shows app executables like httpd, sshd, postgres and a
custom daemon using the new shared libraries.
Now, how to go into fips_mode:
Q1. Can I make these executable go into fips_mode by a config or tune
without changing their source and without recompiling them?
In general, no. Except for the most trivial of applications you'll
inevitably need *some* source mods. Perhaps not much, but some.
Chapter five of the OpenSSL FIPS User Guide
(http://www.openssl.org/docs/fips/UserGuide-1.2.pdf) has a discussion on
what may be needed. Please read it. Note in particular section 5.6, as
some pundits incorrectly claim that a separate FIPS validation is
required even where the OpenSSL FIPS Object Module is used as intended.
In a nutshell:
- The application must use OpenSSL for *all* cryptographic operations.
- CSPs (Critical Security Parameters, i.e. private keys) must be
"zeroized" (memory locations overwritten) after use.
- FIPS mode of operation must be enabled.
- The application should provide a runtime indication that FIPS mode is
enabled. While not a hard requirement, the whole point of enabling FIPS
mode is checklist compliance, so you want reviewers to confirm that
compliance easily.
Q2. If I have to recompile the apps, is it only a recompile, or does
there need to be a function call to FIPs_mode_set(...) or
OPENSSL_config(...). In the OPENSSL_config man page, NOTES,
paragraph 2, there is some automatic way so long as the preprocessor
symbol OPENSSL_LOAD_CONF is #defined and the app calls
OPENSSL_add_all_algorithms().
FIPS_mode_set() *must* be called, either explicitly or implicitly as via
OPENSSl_config(). If you don't call FIPS_mode_set() then FIPS mode is
not enabled. There is no other way to enable FIPS mode.
Note however that the demand for FIPS validated software often stops
with procurement -- I think it's fair to say that most validated
software is not FIPS enabled at runtime. So you probably don't want to
unconditionally hard-code the FIPS_mode_set() call; the customer may
decide to not enable FIPS mode. Additionally, you can ship the same
binary to all customers.
Q3. If the above function call(s) needs to be added, how about other
changes like looking for the return code for ciphers now blocked by
fips_mode so the app deals with it? Probably a good idea.
An excellent idea, though if you stick to the conventional EVP level
calls that job is done for you. However, many applications allow a
ciphersuite to be specified as a runtime configuration option. You may
want to gracefully catch and report any non-allowed algorithm selections
as the config options are parsed instead of failing much later as the
algorithm invocation fails. Also many apps have a default ciphersuite
that contains non-allowed algorithms.
Q4. If source changes are required, are these publicly available as
patches somewhere?
Steve Henson has posted a mod_ssl patch to enable FIPS mode. There are
several versions of patches for OpenSSH based on one I did several years
ago. Stunnel has official FIPS mode support. I'm told the mod_tls and
mod_sftp modules for the proftpd FTP have FIPS mode support. I've heard
about but have not seen patches for cURL.
Q5. To find every app executable on the host which links to libssl.so
and libcrypto.so, I did a global host search with file path and
grepped for some strings and then ran ldd on those looking for
libssl|libcrypto and found about 85 in total. To be FIPS-140-2
compliant, does every one of these need to be able to go into fips
mode? Who determines which ones need to and don't need to?
If you want to claim that the entire host system uses FIPS validated
cryptography then yes, *all* crypto must be validated. Note that as a
practical matter few such systems exist at present -- as you noted
cryptography is ubiquitous. In the case of Linux distributions there is
cryptography in the kernel as well (I'd love to see an open source based
validation of that kernel crypto someday -- IMHO it's possible).
As a practical matter in my DoD consulting I'm seeing demands by risk
assessors for FIPS validation of specific applications (web servers,
database engines), but not for entire hosts. Universal FIPS validation
is a formal requirement in DoD, however.
Q6. Lastly, how can I prove externally of the app that it is in fips
mode. eg; can I ssh -v -c blowfish-cbc u...@host and verify that
a fips_mode sshd will not allow it because blowfish is not supported
in fips mode?
You can never "prove" that an application is FIPS validated. It's all a
paper chase -- NIST recommends that a written vendor statement be
obtained with all procurements of FIPS validated software (sound
advice). Stick that letter or the paper trail I recommend in section
5.6 of the User Guide in your file cabinet and wave it at the auditor or
risk assessor as needed. However, in that User Guide I also recommend
that some indication that FIPS mode is enabled be provided where
possible, using OpenSSH as a specific example (the OpenSSH patches
include that banner notation as well).
The fact that a SSH peer doesn't support blowfish tells you nothing
about FIPS mode or FIPS validation. A SSH implementation that *does*
support blowfish obviously is not properly in FIPS mode (even if you
have the procurement paperwork and vendor letter stating otherwise, as
happened to me :-).
-Steve M.
--
Steve Marquess
Open Source Software institute
marqu...@oss-institute.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
