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 at 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 <satya at attivonetworks.com > <mailto:satya at attivonetworks.com>> 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
