The Doctor wrote:
On Thu, Sep 25, 2008 at 08:22:11AM -0400, Steve Marquess wrote:
David Jacobson wrote:
Tim Hudson wrote:
The Doctor wrote:
That being said, how do you get openssl to compile with FIPS
and be backwards compatable at the same time?
That is what the FIPS mode is for - the library built supports all
algorithms and when in FIPS mode it disables the use of non-approved
algorithms.
A single application can work in both FIPS and non-FIPS mode. You can add
in code to choose which mode to be in on a per-connection basis if that
is what your application requires.
See the usage of FIPS_mode_set()
Note also that due to an implementation quirk you need to clear the
currently set RNG when switching back into FIPS mode.
It is not an implementation quirk, it is a requirement of FIPS 140. FIPS
140 requires that when switching modes all keys and "critical security
parameters" must be cleared. The random number generator state is a
critical security parameter. (I'm doing this from memory, but I'm quite
sure I've got it right.)
It is an implementation quirk (or to be honest, an outright goof). By the
time we caught this problem it was too late to fix it (with the FIPS 140
validation process you freeze your code first, *then* test -- ready, fire,
aim!).
Maybe I don't understand what you mean by "clearing" the RNG. I was
interpreting that to mean zeroizing its state. If you mean something
else, stop reading right here.
From "Implementation Guidance for FIPS PUB 140-2 and the Cryptographic
Module Validation Program" Section 1.2; see the sentence right after
"Resolution".
Definition
Approved mode of operation: a mode of the cryptographic module that employs
only Approved security
functions (not to be confused with a specific mode of an Approved security
function, e.g., DES CBC mode).
Question/Problem
Are there any operational requirements when switching between modes of
operation, either from an Approved
mode of operation to a non-Approved mode of operation, or vice versa?
Resolution
In addition to the requirements specified in AS01.02, AS.01.03 and AS.01.04, a
module shall not share CSPs
between an Approved mode of operation and a non-Approved mode of operation.
Additional Comments
This separation mitigates the risk of untrusted handling of CSPs generated in
an Approved mode of operation.
Examples:
- a module may not generate keys in a non-Approved mode of operation and then
switch to an
Approved mode of operation and use the generated keys for Approved services.
The keys may have
been generated using non-Approved methods and their integrity and protection
cannot be assured.
- a module shall not electronically import keys in plain text in a non-Approved
mode of operation and
then switch to an Approved mode of operation and use those keys for Approved
services.
- a module may not generate keys in an Approved mode of operation and then
switch to a non-
Approved mode of operation and use the generated keys for non-Approved
services. The integrity and
the protection of the Approved keys cannot be assured in the non-Approved mode
of operation.
You see that it says that a module cannot share Critical Security
Parameters (CSPs) between an Approved mode and a non-Approved mode.
Section 7.6 says:
ANSI X9.31 specifies that the seed shall also be kept secret. As such, the seed
is considered a CSP and shall
meet all the requirements pertaining to CSPs.
So we see that the seed is considered a CSP. (You could argue that this
only applies to RNG designs based on ANSI X9.31, but I believe the CMVP
would balk if you tried to use that argument.)
Different documents use different terminology for the internal state,
but I believe that "seed" in the above means not just the initial value,
but the internal state. (Sorry, I don't have a copy of ANSI X9.31 to
check on the definition used there.)
Now you see what I said that it is a requirement, not a quirk, that the
RNG (state) is cleared when transitioning in or out of FIPS mode.
-- David Jacobson
Since there is little practical reason to disable FIPS mode once enabled
(reference earlier discussion) we elected to just leave that bug as-is
rather than abort and restart the validation process.
-Steve M.
--
Steve Marquess
Open Source Software Institute
[EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
The end gives up either to choose FIPs and non-MD5 or non-FIPS and MD5.
Please fix as compilation quirks on this is not a laughing
matter.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
