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? 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? Chris Brook
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ben Laurie Sent: Friday, September 05, 2003 5:56 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FIPS mode Verdon Walker wrote: > 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. 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 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]
