<div dir="ltr"><div>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:<br></div><div><div><font face="monospace, monospace">michael@osiris:~$ readelf -n /usr/lib/x86_64-linux-gnu/libcrypto.so</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Displaying notes found at file offset 0x000001c8 with length 0x00000024:</font></div><div><font face="monospace, monospace"> Owner Data size<span class="" style="white-space:pre"> </span>Description</font></div><div><font face="monospace, monospace"> GNU 0x00000014<span class="" style="white-space:pre"> </span>NT_GNU_BUILD_ID (unique build ID bitstring)</font></div><div><font face="monospace, monospace"> Build ID: 1e5fca06588d1d7c0f8f4b16c82611e6be697fb2</font></div></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>"As long as politics is the shadow cast on society by big business, the attenuation of the shadow will not change the substance."</div><div><br></div>Dewey, J. (2008). <i>The later works of John Dewey, 1925 - 1953</i> (Volume 6, page 163). Carbondale, IL: Southern Illinois University Press.<br></div></div></div>
<br><div class="gmail_quote">On Tue, Mar 15, 2016 at 5:38 PM, Satya Das <span dir="ltr"><<a href="mailto:satya@attivonetworks.com" target="_blank">satya@attivonetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Steve,<br>
<br>
How does one get a hold of the embedded signature in libcrypto.so ?<br>
<br>
Thanks<br>
<span class="im HOEnZb"><br>
-----Original Message-----<br>
From: openssl-users [mailto:<a href="mailto:openssl-users-bounces@openssl.org">openssl-users-bounces@openssl.org</a>] On Behalf Of Steve Marquess<br>
</span><span class="im HOEnZb">Sent: Tuesday, March 15, 2016 3:54 PM<br>
To: <a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so<br>
<br>
</span><div class="HOEnZb"><div class="h5">On 03/15/2016 05:24 PM, Satya Das wrote:<br>
> Hello Steve,<br>
><br>
> Even if a vendor letter is good for CMVP, how is the vendor supposed<br>
> to know ?<br>
<br>
Ummm, because the vendor is the one who created the validated module.<br>
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).<br>
<br>
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.<br>
<br>
> I would say openssl should give such a tool so that vendor and the<br>
> testing Lab can know such things. It is more than critical that the<br>
> applications link to the intended crypto module. This convoluted and<br>
> complex object module linking etc. with 207 page user guide is<br>
> specific to openssl's approach to FIPS, and therefore should be<br>
> addressed by the project. It should not come down to some vendor<br>
> document written in good faith.<br>
<br>
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.<br>
<br>
-Steve M.<br>
<br>
--<br>
Steve Marquess<br>
OpenSSL Validation Services, Inc.<br>
1829 Mount Ephraim Road<br>
Adamstown, MD 21710<br>
USA<br>
<a href="tel:%2B1%20877%20673%206775" value="+18776736775">+1 877 673 6775</a> s/b<br>
<a href="tel:%2B1%20301%20874%202571" value="+13018742571">+1 301 874 2571</a> direct<br>
<a href="mailto:marquess@openssl.com">marquess@openssl.com</a><br>
gpg/pgp key: <a href="http://openssl.com/docs/0x6D1892F5.asc" rel="noreferrer" target="_blank">http://openssl.com/docs/0x6D1892F5.asc</a><br>
--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br></div>