On June 22, 2004 10:09 AM Chris Brook wrote:
>When we did FIPS 140 certification, we had a similar problem in
>that the sys admin could select the encryption and hash algorithms
>that he wanted to use in his environment. Obviously MD5, for
>example, is not a valid algorithm, so the system could not use
>that and be in "FIPS mode". We addressed it through the Security
>Policy which said simply that if the security officer wanted the
>system to be in FIPS mode, then the system must be configured to
>use ONLY the following algorithms: a,b,c etc. Use of anything else
>(beyond our control as vendors) automatically put the system in
>non-FIPS mode. This put the responsibility squarely on the security
>officer (and operator of the system). Preesumably neither NIST nor
>the test lab had a problem with this approach since certification
>was granted twice.
>
>Enforcing it in code is only practical if you control the build and
>distribution of the product and it's for a captive audience.
Chris:
You are entirely correct that NIST does not *require* that
non-FIPS algorithms be actively disabled by the implementation
under test. However, FIPS 140 does require that non-FIPS
algorithms not be used by an application claiming FIPS 140
compliance. When the same vendor provides both the validated
cryptographic module (library in this case) and the application
that vendor can be careful to refrain from improper use of FIPS
algorithms, and so affirm for the customers/end users. However,
we don't know what applications may choose to use the FIPS
library and can't vouch for them.
Since the purpose of this OpenSSL validation is to provide a
general purpose FIPS 140 validated library for use by applications
as yet unknown, we wanted to keep it simple both for the developer
and for potential critics. The OpenSSL library behaves the same
as always if FIPS mode isn't enabled, and you can't use non-FIPS
algorithms anyway in FIPS mode, so there is no harm in disabling
the non-FIPS algorithms. As I have found in patching OpenSSH and
Stunnel, avoiding non-FIPS algorithms at the application level can
be non-trivial; one could easily overlook invocation of non-FIPS
algorithms in adapting an existing application. Disabling non-FIPS
algorithms within OpenSSL guards against such accidental use.
If we relied just on a Security Policy admonition the question
of whether a given application properly avoided use of the non-FIPS
algorithms could arise, possibly leading to demands for separate
FIPS 140 validation of the application. The whole point of this
OpenSSL validation was to avoid the need for separate validations
of applications.
Note we do not need to disable all possible uses of non-FIPS
algorithms in all circumstances, just catch the typical usages on
a good faith basis.
-Steve M.
Steve Marquess
DMLSS Technical Manager
JMLFDC, 623 Porter Street, Ft. Detrick, MD 21702
DSN 343-3933, COM 301-619-3933, FAX 301-619-7831
[EMAIL PROTECTED]
