I have a slightly non-standard (and non-security-policy-compliant)
FIPS mode setup, generated with:
cvs -d/home/kyle/openssl/repository co -rOpenSSL_FIPS_1_0 \
-d /home/kyle/openssl/work openssl
./config fips --prefix=/home/kyle
(the 'non-security-policy-compliant' part comes from the extra
parameter to ./config -- I can't touch the OpenSSL build that's
already in the system directories, and the security policy states that
no other parameters can be passed to ./config. [if that's true, it
should test for it.])
I create a file called main.c, with the appropriate code in the
security policy document (minus the #ifdefs and the check for the
preference). I compile it:
~/work$ gcc -I../include -c main.c -o main.o
This step works fine. However, I try to do the standard link:
I poke around, and realize that there's now a 'fipsld' in my
$HOME/bin/ directory. I run it, and it gives me "$(CC) not set".
~/work$ CC=gcc; export CC
no -o specified
Now, I'm figuring it out, step by step, and I decide to go for broke:
~/work$ fipsld main.o -L../lib -lcrypto -lssl -ldl -o fipsme
*** IN FIPS MODE ***
and that works.
The security policy makes no mention of the requirement to use the
'fipsld' command. In fact, the security policy's 'testing' code is
incorrect (as far as it goes) -- it should, in my view, result in a
compilable program that can be used to verify that the library will go
into FIPS mode. (The SP also fails to mention that you can't use the
library in non-FIPS mode without the use of the fipsld command.)
So, to recap:
Compile your application as normal.
Instead of the standard linker, set $(CC) to the value of the same C
compiler, and use 'fipsld' to link.