[openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

Tue Mar 15 20:58:04 UTC 2016

During the linking process, parts of fipscanister.o are removed (discarded)
by the linker. Also, jumps and call instructions have their operands
changed (addresses are filled in or relocation information is added) and
the machine code is fundamentally altered.

Imagine the linking process as something analogous to baking a cheese
quiche with tomatoes. The can of tomatoes you use (i.e., the fipscanister.o
file) is opened. The metal can is discarded along with any liquid inside
the can. Then the tomatoes are placed into the quiche and baked. Melting
cheese seeps into the tomatoes and the tomatoes are physically deformed and
soften. At the end you have a delicious quiche. Can you get the original
can of tomatoes back, in its unmodified form, at this point? Can you
identify exactly which can of tomatoes was used to make this quiche, given
only photos of all the cans prior to opening them?
On Mar 15, 2016 11:22 AM, "Satya Das" <satya at attivonetworks.com> wrote:

> Hello Steve,
>
> Thank you for your comments.
>
> Is there a way to verify that the correct version of object module
> (fipscanister.o) was assimilated into the libcrypto.so ?
> I just need some surefire way to run an engineering check on the build.
> Essentially what my question boils down to, is
> that there is code in there somewhere that comes up with the run time hash
> and compares with the embedded hash.
> Is there a way to use those code pieces to somehow double check that the
> embedded hash matches the object module that
> libcrypto should have been linked to ?
>
> Please note that I am not automating the build, which has been discouraged
> in the User Guide
> (yes I have read probably around 40% of it). However because of the
> complex build flow I want
> to have a post build manual check before using the openssl rpm in rest of
> the product.
>
> Thanks
>
> ________________________________________
> From: openssl-users <openssl-users-bounces at openssl.org> on behalf of
> Steve Marquess <marquess at openssl.com>
> Sent: Tuesday, March 15, 2016 6:02 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
>
> On 03/14/2016 08:30 PM, Satya Das wrote:
> > Hello,
> >
> >
> >
> > I have a simple problem I am trying to solve. I have built a fips
> > capable openssl shared object (.so). I also have the sha1 hash of the
> > fipscanister.o in a file called fipscanister.o.sha1. I also have the
> > sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In
> > order to make sure the build is good, I want to make sure that the .so
> > was indeed built with these versions of fipscanister.o and fips_premain.
> >
> >
> >
> > Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> > object module 2.0.11 from openssl 1.0.1e with patches.
>
> Hmmmm.  Several comments:
>
> 1) Please read the OpenSSL FIPS User Guide,
> https://openssl.org/docs/fips/UserGuide-2.0.pdf. It answers most (I
> would even say all) of your questions. Yes, it's a long dull slog to
> read but then open source FIPS 140-2 is a horribly convoluted topic.
>
> 2) The libcrypto shared library is just an application in the context of
> FIPS 140-2, and in general you're not going to be able to reconstruct an
> object module file (foo.o) from an executable binary image that was
> built from it. Nor is there any FIPS 140-2 related requirement to do so.
>
> 3) The fipscanister.o file is a little bit more (and less) that your
> typical object module ("module" in the usual software engineering sense.
> It is discussed in the OpenSSL FIPS User Guide, in particular section
> 2.3.2.
>
> Note the SHA1 digest of the libcrypto shared library file, or of any
> other application, is completely irrelevant to FIPS 140-2. In fact the
> CMVP specifically disallowed any integrity test that contained such
> "extraneous" data (see section 2.3.1). We were told at the time that was
> because of the risk of SHA1 digest collision.
>
> 3) The "file integrity chain" (section 2.4) requires that the interim
> files created from the official source distribution tarball be verified
> using SHA1 hashes. Somewhat oddly, given the rather intense focus on
> ideological righteousness elsewhere, you're allowed to do this with an
> un-sanctified SHA1 implementation. Notice for instance that the stock
> build process uses an interim utility ("./fips/fips_standalone_sha1")
> built from the same code as used in the FIPS module.
>
> Also note that this is first and foremost a procedural or paperwork
> chain. You can have two software products that claim to use FIPS 140-2
> validated crypto, and those can be bit-for bit identical, yet with one
> satisfying the FIPS 140-2 validation requirements and one not; no
> conceivable technical test can distinguish them (we call this difference
> FIPS "magical pixie dust").
>
> 4) The canonical FIPS module integrity test, common to all FIPS modules,
> takes the form of the "incore integrity test" for the OpenSSL FIPS
> module (discussed in detail in -- you guessed it -- the User Guide).
> Note that this incore integrity test does *not* include all of the
> contents of the fipscanister.o object file.
>
> 5) As Jakob has correctly noted, there is no point in trying to automate
> the FIPS module build-from-source; you'll lose the FIPS 140-2 magical
> pixie dust of righteousness which is the whole, entire, and only point
> of using the FIPS module. Section 5.5 has some recommendations, which I
> often summarize by suggesting the module ("fipscanister.o" et. al.) be
> built once in a solemn candle-lit ceremony and only those resulting
> install targets preserved (no point in keeping the source, it can't be
> changed and can't even be transferred via the usual common sense means).
> At a minimum you'll need an official CD (section 6.6; yup, snail mail is
> a "trusted path"). We're still sending those out for free, in spite of
> the significant financial losses the OpenSSL FIPS business sustained
> last year.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/8c1f4344/attachment.html>