FIPS mode
Ben Laurie
if people have comments/changes/concerns, they'd better get a move on
and clue me in, because once its done we can't change it.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Ben Laurie
> After reviewing the email archives for both the developer and user
> groups, I have a lot of questions:
Answers in quotes were written by someone else, answers not in quotes
are my own.
> - What platforms are being FIPS certified?
"The formal test platform is HP-9000/HP-UX 11i. However, NIST/CSE are
certifying the software at the source code level (a first) and have
stated that when the certified source is merely recompiled for another
platform the FIPS-140 certification still applies."
> - Is it FIPS 140-2?
"Yes, FIPS-140-2 level 1"
> - What version of OpenSSL does it correspond to? 0.9.7b?
"Yes, and the FIPS specific routines will be carried forward in future
OpenSSL releases. Only the "cryptographic module" containing the
relevant cryptographic module implementations is certified, not the
larger OpenSSL distribution which can change without affecting the
certification."
What I've done is to make copies of the code that constitute the
cryptographic module, and use those instead of the base versions. This
allows two things to be done. Firstly, the base distribution can be
changed without affecting FIPS certification. Secondly, it means changes
required by FIPS can be isolated in the certified code. For example,
FIPS requires an approved PRNG, but I am not up for replacing OpenSSL's
PRNG with X9.17 except in FIPS mode.
> - Are both the static libraries and dynamic libraries to be certified?
> If not, which?
"Both (or neither); the certification is at the source code level. As
long as the "pedigree" of the certified source is tracked through the
process of generating and referencing build-time and run-time code the
FIPS-140 certification applies."
There are checksums for the certified source included. The build process
checks them, then generates a checksum for the resulting library. An
application wishing to use the FIPS version of OpenSSL should check the
library checksum before linking, then generate a checksum for itself
after linking. This checksum should then be checked at startup. I will
be adding more support for this process soon.
Applications do need minor modification to switch on FIPS mode (it is
optional, even in the FIPS build of OpenSSL, by design), and also
typically to avoid using unapproved algorithms (which in general don't
work in FIPS mode). I've been considering having it optionally (at build
time, of course) start out switched on, but given that very few apps can
actually run correctly in FIPS mode without some modification, the
motivation for that is not huge.
> - What is the strategy for introducing bug fixes into the FIPS
> OpenSSL?
"NIST permits some degree of modification without requiring a
re-certification, based on a vendor affirmation of the extent of
changes. The "vendor" for this purpose for OpenSSL will be the Open
Source Software Institute (http://www.oss-institute.org/) which has
coordinated the FIPS-140 certification effort. Extensive changes to the
cryptographic algorithms will require certification. The "cryptographic
module" containing these algorithm implementations has been segregated
within the OpenSSL distribution in order to maximize the validity of the
FIPS-140 certification."
> Basically, I would like to know a lot more about what has happened so
> far, where the certification process is, etc. The threads in the email
> archives basically show that doing the work was discussed, but not
> really settled. Then suddenly a note that the code has been moved to its
> own branch and now this message saying it's almost too late to have any
> input. What happened to the discussion about the ongoing work?
The discussion about the ongoing work has been mostly amongst the team
doing the work, of which only I am involved in OpenSSL development.
Unfortunately, this is almost entirely conducted in conference calls.
There was also a desire on the part of the sponsors of the project to
keep its profile low until we were close to certification, for reasons
that I hope are obvious.
Nevertheless the code showing the approach was posted many weeks ago,
not sprung on you just now, with only a few weeks to go. All that's
changed recently of any substance is code to generate the test vectors
required for certification. It is unfortunate that the process could not
have been more open, but I considered the goal worth that sacrifice,
especially since the community has been given ample opportunity, in my
view, to give its input. Nevertheless, I will do my best to respond to
any feedback you or anyone else has, as, I am sure, will other members
of the team (who have already been most helpful, thankyou).
Also, all the supporting documentation will be made available (another
first, I believe), so future certification efforts (if needed) will be
substantially easier to do.
Mathias Brossard
> > - What version of OpenSSL does it correspond to? 0.9.7b?
>
> "Yes, and the FIPS specific routines will be carried forward in future
> OpenSSL releases. Only the "cryptographic module" containing the
> relevant cryptographic module implementations is certified, not the
> larger OpenSSL distribution which can change without affecting the
> certification."
Out of curiosity, which cryptographic module are certified ? A quick
google, tells me the list of approved "security functions" should be
approximately:
- Symmetric: AES, DES, 3DES, Skipjack
- Asymmetric: DSA, RSA, ECDSA
- Message Authentication: DES MAC, Triple DES MAC
- Hash: SHA-1
- Keyed Hash: HMAC
- RNG: FIPS 186-2 (Appendix 3.1 & 3.2), ANSI X9.31 and ANSI X9.62
Sincerely,
--
Mathias Brossard <mathias....@idealx.com>
Rich Salz
> have been more open, but I considered the goal worth that sacrifice,
Not a problem for me. :)
This is great -- one of the most exciting things I've seen in a long time!
/r$
--
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
Ben Laurie
> On Fri, 2003-09-05 at 11:55, Ben Laurie wrote:
>
>>>- What version of OpenSSL does it correspond to? 0.9.7b?
>>
>>"Yes, and the FIPS specific routines will be carried forward in future
>>OpenSSL releases. Only the "cryptographic module" containing the
>>relevant cryptographic module implementations is certified, not the
>>larger OpenSSL distribution which can change without affecting the
>>certification."
>
>
> Out of curiosity, which cryptographic module are certified ?
None, yet, but those that we are shooting for are...
> A quick
> google, tells me the list of approved "security functions" should be
> approximately:
> - Symmetric: AES, DES, 3DES, Skipjack
AES, DES, 3DES (2 and 3-key modes).
> - Asymmetric: DSA, RSA, ECDSA
Not my understanding. Anyway, DSS only. RSA can't be, and ECDSA we
aren't doing.
> - Message Authentication: DES MAC, Triple DES MAC
Nope.
> - Hash: SHA-1
Yep.
> - Keyed Hash: HMAC
Nope.
> - RNG: FIPS 186-2 (Appendix 3.1 & 3.2), ANSI X9.31 and ANSI X9.62
X9.17.
Cheers,
Ben.
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Ben Laurie
> If I read your reply right, responsibility for DAC and Known Answer Test
> checking is the responsibility of the app developer, though you will provide
> the DAC checksum for the crypto module. Have you also included the KATs,
> since they essentially exist the OpenSSL test modules?
_Everything_ is included.
> Since OpenSSL is providing source code (which presumably includes the DAC
> checksum generation code), what's to prevent a user modifying the crypto
> code and regenerating the checksum?
Nothing. What's to prevent you claiming you're using FIPS-140 certified
stuff and not doing so? Nothing. That's not the way it works.