understanding fipsld usage

[Kevin Fowler]

Let me first say I have read the User Guide and Security Policy
repeatedly, as well as the Incore Tutorial, looked through this users
group, and read anything else I could find - so I'm not being lazy,
although my questions may be pedestrian... Please correct any
misunderstandings along the way.

I understand that when fipscanister.o is built, its SHA1 digest is
calculated and saved. Then when an application links to
fipscanister.o, fipsld is used, which checks that the SHA1 is correct,
and then calculates the digest for the application and rebuilds it
with that digest embedded. Then, when the application is run and calls
FIPS_mode_set(), the digest is calculated and checked against the
embedded value.

I think that openssl itself is an example of an application built with
the fipscanister.o, is that correct?

When OpenSSL is built, it produces, among other things, the
libcrypto.a static library, which contains what was sequestered in
fipscanister.o.Is that correct?

Now I have a big application to build, and it will have the
FIPS-capable OpenSSL in it. When I do the build, I think the
instructions say that the SHA1 digest has to be re-calculated on this
application, and that value embedded where the previous standalone
value was. Is that correct?

Is my application pulling in the FIPS stuff by linking in the libcrypto.a?

If my application is just too large and complex, do I pretty much need
to go with the shared library, and avoid the part where the digest is
recalculated/re-embedded in the application itself?

Thanks
Kevin
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Dr. Stephen Henson]

On Fri, Nov 18, 2011, Kevin Fowler wrote:

> Let me first say I have read the User Guide and Security Policy
> repeatedly, as well as the Incore Tutorial, looked through this users
> group, and read anything else I could find - so I'm not being lazy,
> although my questions may be pedestrian... Please correct any
> misunderstandings along the way.
>
> I understand that when fipscanister.o is built, its SHA1 digest is
> calculated and saved. Then when an application links to
> fipscanister.o, fipsld is used, which checks that the SHA1 is correct,
> and then calculates the digest for the application and rebuilds it
> with that digest embedded. Then, when the application is run and calls
> FIPS_mode_set(), the digest is calculated and checked against the
> embedded value.
>
> I think that openssl itself is an example of an application built with
> the fipscanister.o, is that correct?
>

It depends on what you mean by "openssl" and the build options. If you are
performing a shared library build then fipscanister.o is embedded in the
libcrypto shared library. For a static build every application including the
"openssl" utility statically includes fipscanister.o

> When OpenSSL is built, it produces, among other things, the
> libcrypto.a static library, which contains what was sequestered in
> fipscanister.o.Is that correct?
>
> Now I have a big application to build, and it will have the
> FIPS-capable OpenSSL in it. When I do the build, I think the
> instructions say that the SHA1 digest has to be re-calculated on this
> application, and that value embedded where the previous standalone
> value was. Is that correct?
>
> Is my application pulling in the FIPS stuff by linking in the libcrypto.a?
>
> If my application is just too large and complex, do I pretty much need
> to go with the shared library, and avoid the part where the digest is
> recalculated/re-embedded in the application itself?
>

If you're library links against the OpenSSL shared library you don't need to
bother with any of this as the fingerprint is embedded in that shared library
by the build process.

If you want to statically link against OpenSSL you do need to address this.
If you're using a Unix like system then making some minor adjustments to the
final linking to use fipsld and set a few environement variables is
sufficient. If you want to integrate this with some IDE or you are using
Windows with an IDE then this is a bit trickier and you might need to develop
your own procedure following the security policy requirements.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

[Kevin Fowler]

Thanks Steve, I have a follow-up below - just checking I have it straight.

On Mon, Nov 21, 2011 at 10:11 AM, Dr. Stephen Henson <st...@openssl.org> wrote:
> On Fri, Nov 18, 2011, Kevin Fowler wrote:
>
>> Let me first say I have read the User Guide and Security Policy
>> repeatedly, as well as the Incore Tutorial, looked through this users
>> group, and read anything else I could find - so I'm not being lazy,
>> although my questions may be pedestrian... Please correct any
>> misunderstandings along the way.
>>
>> I understand that when fipscanister.o is built, its SHA1 digest is
>> calculated and saved. Then when an application links to
>> fipscanister.o, fipsld is used, which checks that the SHA1 is correct,
>> and then calculates the digest for the application and rebuilds it
>> with that digest embedded. Then, when the application is run and calls
>> FIPS_mode_set(), the digest is calculated and checked against the
>> embedded value.
>>
>> I think that openssl itself is an example of an application built with
>> the fipscanister.o, is that correct?
>>
>
> It depends on what you mean by "openssl" and the build options. If you are
> performing a shared library build then fipscanister.o is embedded in the
> libcrypto shared library. For a static build every application including the
> "openssl" utility statically includes fipscanister.o
>

Ok, so:
- if I do a shared build of OpenSSL (./config fips shared), then the
libcrypto.so that is produced contains the FIPS Object Module, and
fipsld will have embedded the digest in that library.
- if I do a static build of OpenSSL (.config tips), then the
libcrypto.a that is produced does not contain the FIPS Object Module.
Later linking to an application will require fipscanister.o, -L
lcrypto, and the use of fipsld to embed the digest in the application.
An example of this is the hello application in the Incore Tutorial
document.