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
[email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
