I have some doudt regarding fips capbable openssl... If in my system , one of the my application gets into fips mode .. whether that going to effect other application to use fips enabled cryptography alogorithm.. .I have seen in some fips enabled library, if one application gets into fips mode , whole library will be in fips mode and all the application in the system will be in fips mode. is this true for openssl ? Is the fips enabled at system level or application .
Thanks Rajan On Sun, Mar 1, 2009 at 4:22 AM, Steve Marquess <marqu...@oss-institute.org>wrote: > Kyle Hamilton wrote: > >> > ... Yes, the fipsld script proper is not required (for the Windows >> > platform it isn't used at all). However, the two step linking >> > operation that fipsld performs is required. In this sense the >> > cryptographic module boundary at the point where fipscanister.o has >> > been created consists not only of that file but also the ancillary >> > files fipscanister.o.sha1, fips_premain.c, and fips_premain.c.sha1 >> > files. >> >> Er... my biggest question actually wasn't answered here. The >> two-step linking process involves the creation of the library memory >> image/memory segment (which is the entire reason for the >> fips_premain.c requirement, I think?), but is it required that the >> premain function actually be called before the entry point into the >> program itself? If the answer to this is "yes", then it's not >> possible -- the kernel needs to initialize itself and its data >> structures before it can run any other code. If it's simply a >> requirement that the premain code be executed before the library has >> any opportunity to run any other initialization code, then it might >> be possible. >> > > There is no policy requirement to call FINGERPRINT_premain() at any > particular point prior to FIPS_mode_set(). There may be practical > problems, of course, if the integrity check is sabotaged. > > > ... >> >> Legally speaking (and this is primarily coming from the Free Software >> Foundation's pages), the license of OpenSSL prevents the >> distribution of a GPL'd software that links directly to it (in a >> monolithic sense), unless the copyright owner of the GPL-licensed >> software adds an explicit exemption for OpenSSL's "obnoxious BSD >> advertising clause" requirement. This legal issue essentially makes >> it a non-starter in the monolithic kernel concept currently >> discussed. >> > > Good point about the licensing implications, I didn't address that topic at > all. > > > So, if the reason for adding the crypto to a kernel module was to >> > support a userspace application one could speculate that the >> > application could be FIPS validated independently of that kernel >> > and hence that kernel module. If the reason was to claim FIPS >> > validation for the entire kernel then you have a much bigger >> > problem because of the other existing crypto in the kernel. >> >> This would be a VERY interesting mechanism to bring into the mainline >> Linux kernel -- the ability to set a sysparm so that any call to any >> of the crypto implementations will be redirected to the FIPS module >> imported from OpenSSL. >> > > I've had several discussions over the past few years with interested > parties about FIPS validation for the kernel crypto (not using OpenSSL, but > validating the current crypto). I do think it would be possible. So far > the requisite interest level isn't there to make it happen. > > However, there's an additional quandary in this concept: the FIPS >> validation for OpenSSL is explicitly for a "single-user system". This >> specifically means that any system with multiple users is in >> violation of the security policy, and thus not running in a validated >> mode. >> > > Eh, the "single user" business is an odd one. It doesn't (depending on who > in the CMPV you ask, and when!) necessarily mean "user" in the sense us code > hackers think. Note for instance the reference in section 6.1 of the IG > (Implementation Guidance): "... When a crypto module is implemented in a > server environment, the server application is the user of the cryptographic > module. The server application makes the calls to the cryptographic module. > Therefore, the server application is the single user of the cryptographic > module, even when the server application is serving multiple clients." > > A little reflection shows the absurdity of the notions that a) FIPS > validated modules can only be run on "single user mode" systems (in the > usual sense), b) the U.S. government mandates the use of only FIPS validated > crypto on all government systems, and c) nowadays crypto is everywhere, in > the most common of applications. > > The fact is that the CMVP has never coherently reconciled the AS06.04 > requirement with respect to modern general purpose multitasking, demand > paged virtual memory computers as actually used in the real world. I'm > working through that very issue on a pending validation right now, but I > don't expect a resolution beyond that one module. > > ... >> >> The CMVP was never set up to handle people wanting to do weird stuff >> with cryptographic modules for which the source code is available. >> Then again, it was never set up to handle open source in any manner >> anyway. >> > > Actually it's arguably not really set up to deal with software of *any* > kind on general purpose computers, open or closed source. FIPS 140 > originated at a time when cryptography was done in dedicated hardware > devices. It's a pretty strained fit to today's computing environment. FIPS > 140-3 is supposed to less of a mismatch. > > -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 >
