Re: [openssl-users] openssl-users Digest, Vol 16, Issue 26

[Jeffrey Walton]

eremy Farrell <jeremy.farr...@oracle.com>
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
> Message-ID: <56e89cb1.90...@oracle.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 15/03/2016 21:24, Satya Das wrote:
>> Even if a vendor letter is good for CMVP, how is the vendor supposed to know 
>> ?
>
> By remembering whether or not he followed the required procedure; it's
> the only way for him to know.
>
>> I would say openssl should give such a tool so that vendor and the testing 
>> Lab can know such things. It is more than critical that the applications 
>> link to the intended crypto module.
>
> You miss the point. It is no more or less critical that 'the application
> link to the intended crypto module' than countless other things. Many of
> the other things cannot be checked by running a tool. How would a tool
> check that the vendor had executed 'make' at the appropriate stage as
> opposed to (say) '/usr/bin/make'? How would a tool check that the vendor
> had got the original tar file from the OSF CD rather than by downloading it?
>
>> This convoluted and complex object module linking etc. with 207 page user 
>> guide is specific to openssl's approach to FIPS, and therefore should be 
>> addressed by the project. It should not come down to some vendor document 
>> written in good faith.
>
> How can it come down to anything else? What other possible means are
> there for a customer to know that an OpenSSL-based product is FIPS 140-2
> validated?
>
> --
> J. J. Farrell
> Not speaking for Oracle.
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/9378caa8/attachment-0001.html>
>
> --
>
> Message: 3
> Date: Wed, 16 Mar 2016 00:38:39 +
> From: Satya Das <sa...@attivonetworks.com>
> To: "openssl-users@openssl.org" <openssl-users@openssl.org>
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
> Message-ID:
> 
> <bl2pr07mb24047327c36cffea5bc19beed7...@bl2pr07mb2404.namprd07.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Steve,
>
> How does one get a hold of the embedded signature in libcrypto.so ?
>
> Thanks
>
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Steve Marquess
> Sent: Tuesday, March 15, 2016 3:54 PM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what 
> is embedded in libcrypto.so
>
> On 03/15/2016 05:24 PM, Satya Das wrote:
>> Hello Steve,
>>
>> Even if a vendor letter is good for CMVP, how is the vendor supposed
>> to know ?
>
> Ummm, because the vendor is the one who created the validated module.
> Only that vendor can know for sure how the module was created, because the 
> FIPS 140-2 requirements have non-technical procedural elements (think of 
> those as ideological or spiritual elements).
>
> Note that in this context "vendor" refers to the entity that created the 
> validated module and submitted it for FIPS 140-2 validation. The company that 
> uses the FIPS module in their product is a "user", not a "vendor", with 
> respect to the validated module.
>
>> I would say openssl should give such a tool so that vendor and the
>> testing Lab can know such things. It is more than critical that the
>> applications link to the intended crypto module. This convoluted and
>> complex object module linking etc. with 207 page user guide is
>> specific to openssl's approach to FIPS, and therefore should be
>> addressed by the project. It should not come down to some vendor
>> document written in good faith.
>
> But it necessarily always comes down to a vendor document, for *any* 
> validated module, not just the OpenSSL FIPS module.. I've tried and failed 
> now several times to articulate why that is so and can't think of any new way 
> to present it, but it is simply not possible to do what you want; there is no 
> such thing as a magical pixie dust detector. We cannot make one; no one can.
>
> -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
> marqu...@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
>
>
> --
>
> Message: 4
> Date: Tue, 15 Mar 2016 20:48:36 -0700
> From: Mike Mohr <akih...@gmail.com>
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
> Message-ID:
> 

Re: [openssl-users] openssl-users Digest, Vol 16, Issue 26

[rajesh_seetharam]

eck that the vendor had executed 'make' at the appropriate stage as 
opposed to (say) '/usr/bin/make'? How would a tool check that the vendor 
had got the original tar file from the OSF CD rather than by downloading it?

> This convoluted and complex object module linking etc. with 207 page user 
> guide is specific to openssl's approach to FIPS, and therefore should be 
> addressed by the project. It should not come down to some vendor document 
> written in good faith.

How can it come down to anything else? What other possible means are 
there for a customer to know that an OpenSSL-based product is FIPS 140-2 
validated?

-- 
J. J. Farrell
Not speaking for Oracle.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/9378caa8/attachment-0001.html>

--

Message: 3
Date: Wed, 16 Mar 2016 00:38:39 +
From: Satya Das <sa...@attivonetworks.com>
To: "openssl-users@openssl.org" <openssl-users@openssl.org>
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
what is embedded in libcrypto.so
Message-ID:

<bl2pr07mb24047327c36cffea5bc19beed7...@bl2pr07mb2404.namprd07.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

Steve,

How does one get a hold of the embedded signature in libcrypto.so ? 

Thanks

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Steve Marquess
Sent: Tuesday, March 15, 2016 3:54 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is 
embedded in libcrypto.so

On 03/15/2016 05:24 PM, Satya Das wrote:
> Hello Steve,
> 
> Even if a vendor letter is good for CMVP, how is the vendor supposed 
> to know ?

Ummm, because the vendor is the one who created the validated module.
Only that vendor can know for sure how the module was created, because the FIPS 
140-2 requirements have non-technical procedural elements (think of those as 
ideological or spiritual elements).

Note that in this context "vendor" refers to the entity that created the 
validated module and submitted it for FIPS 140-2 validation. The company that 
uses the FIPS module in their product is a "user", not a "vendor", with respect 
to the validated module.

> I would say openssl should give such a tool so that vendor and the 
> testing Lab can know such things. It is more than critical that the 
> applications link to the intended crypto module. This convoluted and 
> complex object module linking etc. with 207 page user guide is 
> specific to openssl's approach to FIPS, and therefore should be 
> addressed by the project. It should not come down to some vendor 
> document written in good faith.

But it necessarily always comes down to a vendor document, for *any* validated 
module, not just the OpenSSL FIPS module.. I've tried and failed now several 
times to articulate why that is so and can't think of any new way to present 
it, but it is simply not possible to do what you want; there is no such thing 
as a magical pixie dust detector. We cannot make one; no one can.

-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
marqu...@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


--

Message: 4
Date: Tue, 15 Mar 2016 20:48:36 -0700
From: Mike Mohr <akih...@gmail.com>
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
what is embedded in libcrypto.so
Message-ID:

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

[Satya Das]

Steve,

How does one get a hold of the embedded signature in libcrypto.so ? 

Thanks

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Steve Marquess
Sent: Tuesday, March 15, 2016 3:54 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is 
embedded in libcrypto.so

On 03/15/2016 05:24 PM, Satya Das wrote:
> Hello Steve,
> 
> Even if a vendor letter is good for CMVP, how is the vendor supposed 
> to know ?

Ummm, because the vendor is the one who created the validated module.
Only that vendor can know for sure how the module was created, because the FIPS 
140-2 requirements have non-technical procedural elements (think of those as 
ideological or spiritual elements).

Note that in this context "vendor" refers to the entity that created the 
validated module and submitted it for FIPS 140-2 validation. The company that 
uses the FIPS module in their product is a "user", not a "vendor", with respect 
to the validated module.

> I would say openssl should give such a tool so that vendor and the 
> testing Lab can know such things. It is more than critical that the 
> applications link to the intended crypto module. This convoluted and 
> complex object module linking etc. with 207 page user guide is 
> specific to openssl's approach to FIPS, and therefore should be 
> addressed by the project. It should not come down to some vendor 
> document written in good faith.

But it necessarily always comes down to a vendor document, for *any* validated 
module, not just the OpenSSL FIPS module. I've tried and failed now several 
times to articulate why that is so and can't think of any new way to present 
it, but it is simply not possible to do what you want; there is no such thing 
as a magical pixie dust detector. We cannot make one; no one can.

-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
marqu...@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

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

[Jeremy Farrell]

On 15/03/2016 21:24, Satya Das wrote:

Even if a vendor letter is good for CMVP, how is the vendor supposed to know ?


By remembering whether or not he followed the required procedure; it's 
the only way for him to know.



I would say openssl should give such a tool so that vendor and the testing Lab 
can know such things. It is more than critical that the applications link to 
the intended crypto module.


You miss the point. It is no more or less critical that 'the application 
link to the intended crypto module' than countless other things. Many of 
the other things cannot be checked by running a tool. How would a tool 
check that the vendor had executed 'make' at the appropriate stage as 
opposed to (say) '/usr/bin/make'? How would a tool check that the vendor 
had got the original tar file from the OSF CD rather than by downloading it?



This convoluted and complex object module linking etc. with 207 page user guide 
is specific to openssl's approach to FIPS, and therefore should be addressed by 
the project. It should not come down to some vendor document written in good 
faith.


How can it come down to anything else? What other possible means are 
there for a customer to know that an OpenSSL-based product is FIPS 140-2 
validated?


--
J. J. Farrell
Not speaking for Oracle.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Steve Marquess]

On 03/15/2016 04:58 PM, Mike Mohr wrote:
> 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?

To a rough first approximation this is true for object code, but the
story is a little more nuanced for the OpenSSL FIPS Object Module. We
create that in a way (the "monolithic" object module) that prevents the
application link process from scrambling what would otherwise have been
an assortment of object modules (in the software engineering sense, not
FIPS-speak).

The premain (native compilation) process, the "incore" utilities
(cross-compilation), and the run-time POST integrity test all calculate
exactly the same digest over exactly the same bits (in our case, the
TEXT and RODATA segments). If the application link process rearranged
any of that TEXT or RODATA then the runtime integrity test would fail.

So very technically speaking the FIPS module is not fipscanister.o, but
the TEXT and RODATA data within it.

To use your analogy, the fipscanister.o "can" contains only one tomato
which is an indigestible and indivisible blob that appears intact in the
baked quiche. Bon Appétit.

-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
marqu...@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

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

[Steve Marquess]

On 03/15/2016 05:24 PM, Satya Das wrote:
> Hello Steve,
> 
> Even if a vendor letter is good for CMVP, how is the vendor supposed
> to know ?

Ummm, because the vendor is the one who created the validated module.
Only that vendor can know for sure how the module was created, because
the FIPS 140-2 requirements have non-technical procedural elements
(think of those as ideological or spiritual elements).

Note that in this context "vendor" refers to the entity that created the
validated module and submitted it for FIPS 140-2 validation. The company
that uses the FIPS module in their product is a "user", not a "vendor",
with respect to the validated module.

> I would say openssl should give such a tool so that vendor and the
> testing Lab can know such things. It is more than critical that the
> applications link to the intended crypto module. This convoluted and
> complex object module linking etc. with 207 page user guide is
> specific to openssl's approach to FIPS, and therefore should be
> addressed by the project. It should not come down to some vendor
> document written in good faith.

But it necessarily always comes down to a vendor document, for *any*
validated module, not just the OpenSSL FIPS module. I've tried and
failed now several times to articulate why that is so and can't think of
any new way to present it, but it is simply not possible to do what you
want; there is no such thing as a magical pixie dust detector. We cannot
make one; no one can.

-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
marqu...@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

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

[Satya Das]

Hello Steve,

Even if a vendor letter is good for CMVP, how is the vendor supposed to know ? 

I would say openssl should give such a tool so that vendor and the testing Lab 
can know such things. It is more than critical that the applications link to 
the intended crypto module. This convoluted and complex object module linking 
etc. with 207 page user guide is specific to openssl's approach to FIPS, and 
therefore should be addressed by the project. It should not come down to some 
vendor document written in good faith.

Thanks again for your comments.


-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Steve Marquess
Sent: Tuesday, March 15, 2016 12:30 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is 
embedded in libcrypto.so

In a word, no. In principle a utility could be written, for most platforms, 
based on the "incore" utilities used for cross-compilation (some of which are 
included in the FIPS module tarball). To my knowledge that has not been done, 
and would be moot anyway because as noted in my original response *no* 
technical test of *any* kind can determine the absence of the procedural "pixie 
dust".

Let me elaborate on that a bit as I didn't get the point across the first time. 
If I build the OpenSSL FIPS module and fail to follow the mandated build 
process exactly, the result is not validated. So for instance any of the 
following failures:

a) I download openssl-fips-2.0.N.tar.gz instead of getting the official 
snail-mailed CD;

b) Neglect to check the tarball digest against the value in Appendix B of the 
Security Policy;

c) Build with "./Configure ..." instead of "./config", even though the build 
options are identical;

d) Edit the README in the ./openssl-fips-2.0.N/ workarea created from the 
tarball;

...mean the result is not validated, even though it may be *exactly* 
bit-for-bit identical with one built without those procedural errors. No 
technical test can verify the presence of the magical pixie dust of FIPS
140-2 righteousness!

Keep in mind that this issue - how do I tell if application X is using FIPS 
module Y -- is the same for *all* FIPS validated cryptography. Most of which is 
proprietary with the content of the module and the digests unknown.

If you ask the CMVP this question they will say "get a letter from the vendor". 
That is a sensible answer; the letter will be the CYA you need for any audit or 
assessment. While you may be able to prove a product does *not* use FIPS 
validated crypto; you can never prove a product contains a righteous FIPS 140-2 
validated module other than with such documentation.

An aside of historical interest: I started getting sucked down the FIPS
140-2 rabbit hole nearly two decades ago, when I had just such a vendor letter 
in hand. But, that vendor kept shipping software that clearly did
*not* use FIPS validated cryptography (I could get it to use non-allowed 
algorithms). After I complained repeatedly that vendor finally confessed "our 
product version that uses the FIPS crypto is very old, you don't want that". 
Well yes I did (i.e. my client did) and insisted on getting the righteous 
product. So the vendor ended up sending us a hand-labeled CD :-(.

The moral of that story is that you should get the vendor letter (or in the 
OpenSSL FIPS module case do the section 5.5 documentation thing) and move on; I 
didn't and was condemned to an eternity of tilting at the FIPS 140-2 windmill...

-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
marqu...@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

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

[Mike Mohr]

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"  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  on behalf of
> Steve Marquess 
> Sent: Tuesday, March 15, 2016 6:02 AM
> To: openssl-users@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.
>
> H.  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 

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

[Steve Marquess]

On 03/15/2016 02:22 PM, Satya Das 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 ?
> 
> ...

In a word, no. In principle a utility could be written, for most
platforms, based on the "incore" utilities used for cross-compilation
(some of which are included in the FIPS module tarball). To my knowledge
that has not been done, and would be moot anyway because as noted in my
original response *no* technical test of *any* kind can determine the
absence of the procedural "pixie dust".

Let me elaborate on that a bit as I didn't get the point across the
first time. If I build the OpenSSL FIPS module and fail to follow the
mandated build process exactly, the result is not validated. So for
instance any of the following failures:

a) I download openssl-fips-2.0.N.tar.gz instead of getting the official
snail-mailed CD;

b) Neglect to check the tarball digest against the value in Appendix B
of the Security Policy;

c) Build with "./Configure ..." instead of "./config", even though the
build options are identical;

d) Edit the README in the ./openssl-fips-2.0.N/ workarea created from
the tarball;

...mean the result is not validated, even though it may be *exactly*
bit-for-bit identical with one built without those procedural errors. No
technical test can verify the presence of the magical pixie dust of FIPS
140-2 righteousness!

Keep in mind that this issue - how do I tell if application X is using
FIPS module Y -- is the same for *all* FIPS validated cryptography. Most
of which is proprietary with the content of the module and the digests
unknown.

If you ask the CMVP this question they will say "get a letter from the
vendor". That is a sensible answer; the letter will be the CYA you need
for any audit or assessment. While you may be able to prove a product
does *not* use FIPS validated crypto; you can never prove a product
contains a righteous FIPS 140-2 validated module other than with such
documentation.

An aside of historical interest: I started getting sucked down the FIPS
140-2 rabbit hole nearly two decades ago, when I had just such a vendor
letter in hand. But, that vendor kept shipping software that clearly did
*not* use FIPS validated cryptography (I could get it to use non-allowed
algorithms). After I complained repeatedly that vendor finally confessed
"our product version that uses the FIPS crypto is very old, you don't
want that". Well yes I did (i.e. my client did) and insisted on getting
the righteous product. So the vendor ended up sending us a hand-labeled
CD :-(.

The moral of that story is that you should get the vendor letter (or in
the OpenSSL FIPS module case do the section 5.5 documentation thing) and
move on; I didn't and was condemned to an eternity of tilting at the
FIPS 140-2 windmill...

-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
marqu...@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

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

[Satya Das]

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  on behalf of Steve 
Marquess 
Sent: Tuesday, March 15, 2016 6:02 AM
To: openssl-users@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.

H.  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 

[openssl-users] openssl 1.0.1p PEM_write_bio_RSAPrivateKey fail. error: ASN1_get_object:too long

[Tekale, Sharad]

Hi Folks,



Need help.



I'm not able to encrypt a key using passphrase, below is the error message.

*"error:0D07209B:asn1 encoding routines:ASN1_get_object:too long"*



Have already googled for error but couldn't got much info





Snippet of my code:



unsigned char pass[] = "123456";

BIO *priv_bio = BIO_new( BIO_s_mem() );

RSA *rsa = RSA_generate_key( 2048, 65537, NULL, NULL )
ret = PEM_write_bio_RSAPrivateKey( priv_bio, rsa, EVP_aes_256_cbc(), pass, 64, 
NULL, NULL );



if(!ret) {

ERR_error_string(ERR_get_error(), buffer);

printf(buffer);

}





The same piece of code is working on openssl-0.9.8zg.



Can I know what's missing or any further debug steps to check this issue?



Thanks,
Sharad.









- CONFIDENTIAL-

This email and any files transmitted with it are confidential, and may also be 
legally privileged. If you are not the intended recipient, you may not review, 
use, copy, or distribute this message. If you receive this email in error, 
please notify the sender immediately by reply email and then delete this email.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Steve Marquess]

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.

H.  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
marqu...@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

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

[Satya Das]

Hello Jakob,

Thank you for the information. So what you are saying is the object module 
build that generated the SHA1s are not the ones that are embedded. That makes 
sense.

So then what would be the best way to validate the build to have consumed the 
right object files ? Is there a way to generate the embedded sha1 sum from a 
given fipscanister.o (or other artefacts from object module build process) ? 

Also how do I locate the embedded sha1 in so ? Is it a symbol I should look for 
in gdb ?

Thanks.


From: openssl-users  on behalf of Jakob Bohm 

Sent: Monday, March 14, 2016 10:38 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is 
embedded in libcrypto.so

Let me explain this a bit more clearly:

The fipscanister.o file (like any other .o file) contains
two things:

1. The actual code and constant data (if any) that needs
   to go in the final .so or program file.  This is what
   will eventually be hashed to produce the embedded sha1
   check.

2. Relocation information on how the linker should adjust
   the code to indicate its location in the .so file (and
   in memory on some platforms) and how other parts of the
   .so file shall be adjusted to indicate the location of
   the code in fipscanister.o.  This data is used and
   removed when creating the copy of the fips canister in
   the .so or program file.

Therefore an sha-1 sum of the fipscanister.o file will
include more (and different) bytes than the fips canister
inside the final .so file, and will thus not match the
sha-1 sum that needs to be embedded inside that .so file.

Also for some build targets, the fips canister inside
the final .so file will similarly not match the in-
memory fips canister in the running program, which is
what the embedded sha-1 sum must match.

Using a 3rd party build script which downloads the source
code from somewhere beyond your control cannot be used as
a secure way to build anything supposedly secure.  Such
build scripts are fundamentally insecure and should not
be used.

On 15/03/2016 05:26, Satya Das wrote:
>
> Hello Ethan,
>
> I am tweaking the centos rpmspec to use my fips object module.  That
> seems to be downloading source tar ball, patching etc.
>
> Please note that the sha1 of the so is not so interesting as the
> embedded sha1 check inside so (when one calls FIPS_mode_set).
> Essentially if I can get the embedded sha1in the so, I can compare
> that with the sha1 I have as part of the object module I have built. I
> am assuming the embedded sha1 is that of fipscanister.o.
>
> Hope that makes sense ?
>
> Thanks.
>
>
> From: Ethan Rahn
> Sent: Monday, March 14, 6:11 PM
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
> To: openssl-users@openssl.org
>
> Is there a reason why you cannot build it from a controlled build
> environment and record the hash of the final .so?
>
> It seems that it would be pretty non-trivial if not impossible to pull
> a .o file from a .so in the exact same format that it went in, such
> that you could check the hash. Being able to check if a .c file is in
> the same state in the .so afterwards seems pretty much impossible
> given all the things that would change in the code with compiling and
> linking in between the .c state and the final .so state.
>
> On Mon, Mar 14, 2016 at 5: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.
>>
>>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
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