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

rajesh_seetharam at thbs.com rajesh_seetharam at thbs.com
Wed Mar 16 03:53:52 UTC 2016


I want to unsubscribe, please tell me how to go about it

my mailbox is flooded with your openssl mails

-----Original Message-----
From: openssl-users-request at openssl.org
Sent: Wednesday, March 16, 2016 9:18am
To: openssl-users at openssl.org
Subject: openssl-users Digest, Vol 16, Issue 26

Send openssl-users mailing list submissions to
	openssl-users at openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
	openssl-users-request at openssl.org

You can reach the person managing the list at
	openssl-users-owner at openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Verifying the sha1 of fipscanister.o with what is
      embedded in libcrypto.so (Steve Marquess)
   2. Re: Verifying the sha1 of fipscanister.o with what is
      embedded in libcrypto.so (Jeremy Farrell)
   3. Re: Verifying the sha1 of fipscanister.o with what is
      embedded in libcrypto.so (Satya Das)
   4. Re: Verifying the sha1 of fipscanister.o with what is
      embedded in libcrypto.so (Mike Mohr)


----------------------------------------------------------------------

Message: 1
Date: Tue, 15 Mar 2016 19:05:34 -0400
From: Steve Marquess <marquess at openssl.com>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
	what is embedded in libcrypto.so
Message-ID: <56E8953E.30100 at openssl.com>
Content-Type: text/plain; charset=windows-1252

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
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc


------------------------------

Message: 2
Date: Tue, 15 Mar 2016 23:37:21 +0000
From: Jeremy Farrell <jeremy.farrell at oracle.com>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
	what is embedded in libcrypto.so
Message-ID: <56E89CB1.90700 at 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 +0000
From: Satya Das <satya at attivonetworks.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
	what is embedded in libcrypto.so
Message-ID:
	<BL2PR07MB24047327C36CFFEA5BC19BEED78A0 at 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-bounces at openssl.org] On Behalf Of Steve Marquess
Sent: Tuesday, March 15, 2016 3:54 PM
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/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
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


------------------------------

Message: 4
Date: Tue, 15 Mar 2016 20:48:36 -0700
From: Mike Mohr <akihana at gmail.com>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
	what is embedded in libcrypto.so
Message-ID:
	<CAJe-LUgN7ucT4St_L=ok_HHEDPYP+jqcVRiV3vLVS=buwUSSNg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

There isn't necessarily any embedded signature in a shared object.  In many
cases, there won't be one.  If your shared object was built with a new
enough version of GCC, hasn't been fully stripped, and its note section has
not been removed during the build process, you can get a SHA-1 checksum
from the binary like this:
michael at osiris:~$ readelf -n /usr/lib/x86_64-linux-gnu/libcrypto.so

Displaying notes found at file offset 0x000001c8 with length 0x00000024:
  Owner                 Data size Description
  GNU                  0x00000014 NT_GNU_BUILD_ID (unique build ID
bitstring)
    Build ID: 1e5fca06588d1d7c0f8f4b16c82611e6be697fb2

The GNU linker generates this value, but for the details of how it is
calculated you'd probably have to refer to the gcc source code.  Depending
on what is being hashed, you may or may not be able to re-calculate that
value at a later time.

Caveat emptor: the build id was likely not designed to prove that the
executable code is unmodified.  Its stated goal is to identify repeatable
builds on the same host with the same tools.

"As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance."

Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6,
page 163). Carbondale, IL: Southern Illinois University Press.

On Tue, Mar 15, 2016 at 5:38 PM, Satya Das <satya at attivonetworks.com> wrote:

> Steve,
>
> How does one get a hold of the embedded signature in libcrypto.so ?
>
> Thanks
>
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Steve Marquess
> Sent: Tuesday, March 15, 2016 3:54 PM
> 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/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
> 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/1f301ce5/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
openssl-users at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 16, Issue 26
*********************************************



******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail.  The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address********



******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail.  The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address.********




More information about the openssl-users mailing list