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
