thank you all for your time On Fri, Feb 27, 2009 at 8:55 PM, Steve Marquess <marqu...@oss-institute.org>wrote:
> Kyle Hamilton wrote: > > The answer to your question is: there might be, but this is FAR > > beyond the level where anyone other than a specialist will be able to > > help you. > > How true. I've hesitated to weigh in on this thread because of the > complications that make my head hurt. > > > This can be done if (and only if) ALL of the following are true: 1) > > you can cobble up an environment where you create the fipscanister > > using only unmodified sources into a binary that will load and run in > > your monolithic environment, only using one of the four command > > lines allowed by the Security Policy; 2) you can link the > > fipscanister.o file into your proprietary kernel, including all its > > validation mechanisms (fips_premain.c); 3) you can port the OpenSSL > > code, 0.9.8j or later, into your proprietary kernel; 4) you can > > perform any steps necessary to configure 0.9.8j to realize that the > > FIPS canister is there. > > > > The security policy states only that the fipscanister.o must be > > created in the manner detailed in the security policy, and > > fips_premain.c must be compiled and linked in. Once it's created, > > you can copy it anywhere, you can do anything with it, as long as you > > don't violate the process of creation. (the process of creation > > includes the embedding of the keyed MAC into the fipscanister.o > > library.) You also cannot edit fips_premain.c, and your build > > environment must include the fipscanister.o.sha1 and > > fips_premain.c.sha1 files. > > A good point. Once you have properly embedded fipscanister.o in an > application you can treat that application just like any other > software. A deployed (installed) validated module is both a thing (the > shared library or special object module in this case) and an > installation process, both of which are constrained by a set of rules > (the Security Policy). The installation process for most validated > products is typically "run setup.exe" or "copy the file(s) from the > distribution CD". In our case the installation process is more > involved. The first part of that installation process which creates > fipscanister.o is a push-button process with little room for creative > license -- you untar the one true tarball, ./config fips, make. The > part of the installation process that takes that fipscanister.o and > incorporates it into an application is *slightly* less constrained. > > > More notably, the security policy does NOT state that you must use > > the provided fipsld script to link. As long as all the steps > > performed by the fipsld script are performed, then you will be able > > to use FIPS_mode_set() from within your monolithic kernel. > > 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. > > So, can the v1.2 fipscanister.o be legitimately used in a linux kernel > module? Theoretically I think it *may* be possible in a technical > sense, though I haven't written any kernel modules myself. Start with > fipscanister.o and the ancillary files, and roll your own fipsld > equivalent that performs the two step link. However, the kernel > contains other crypto that isn't validated (and isn't even from > openssl), so it's an interesting philosophical question to say under > what circumstances what parts of that Linux system can claim to be FIPS > validated. The usual block diagrams included in FIPS validations show > the operating system as one monolithic block, and kernel modules could > legitimately be considered to be part of the core O/S and hence not part > of any userspace application 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. > > At any rate I think that's a scripture question that would have to be > interpreted by the priesthood (the CMVP). It's certainly above my pay > grade. > > -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 >
