RE: Inclusion of FIPS
Jeffrey Altman wrote
>"There are a couple of things
that have been bothering me.
>(1) I'm not sure the use
of .SHA1 files is going to work
> long term on Windows.
First, they are unmanageable
> when it comes to
patches. Second, Windows itself
> modifies the .EXE/.DLL
files to include updating
> binding
information. It seems to me that we need
> to compute the hash
not on the entire .EXE/.DLL file
> but instead exclude
the Run Time Binding data and
> the Resource data.
Then we can store the hash as a
> resource string bound
to the file.
Good questions, and you probably
won't like the answers. This
validation effort is primarily
concerned with Unix platforms,
though Ben did put a call out
for volunteers to work the Windows
issues so we could accommodate
that platform as much as possible.
This validation will be unique in
that the source code itself
is the object of the
validation testing, not a platform
specific binary executable or
library. As such we had to
provide a mechanism for
showing that the cryptographic code
executing in binary form was
derived from the validated
source. We also wanted this
mechanism to be platform neutral;
hence the chain of SHA-1 HMAC
signatures from the source code
to the library object code to
the application executable. Note
this only works for static
linking, or the special case of a
shared library explicitly
loaded with a known path.
The typical validation doesn't
have this problem because it is
for a platform specific binary
where there runtime integrity
check is custom tailored to
the specific runtime environment.
To do what you suggest (exclude
Windows DLL binding and resource
data) we would need a Windows
specific implementation of
FIPS_check_exe(), which as
non-portable code would then require
testing under Windows. We did
not have the funding for that
additional testing, and
support of Windows was not an explicit
goal of the current sponsors.
Any new sponsors interested in
Windows specific support should
contact John Weathersby of the
Open Source Software Institute.
He can coordinate the
arrangements as he did for this current
effort. Cost would probably
be in the $USD15K ballpark,
exclusive of the code
development.
The good news is that at least we
were able to include the x86
specific assembler
optimizations in the validation, courtesy of
IBM. So Linux and *BSD on x86
are covered.
>
>(2) Why is it that the
SHA1 hash of the executable linked
> to LIBEAY32.DLL is
being checked and not the hash of
> LIBEAY32.DLL itself?
Are we truly worried about the
> application being
altered and not the crypto library?"
The crypto library is statically
linked in the application
executable, hence the check of
the entire application verifies
that the embedded crypto code
has not changed. Though as you
noted if the application
executable changes after the *.sha1
file is generated even that
will fail.
-Steve M.
smime.p7s