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-0001.html>
