On 21/03/2017 16:06, Steve Marquess wrote:
On 03/21/2017 10:17 AM, Jakob Bohm wrote:
On 21/03/2017 14:02, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf
Of William A Rowe Jr
Sent: Monday, March 20, 2017 20:59
To: openssl-users@xxxxxxxxxxx
Subject: Re: Static FIPS Library with Address
Randomization
Note you may not modify the openssl-FIPS build files or process.
However, building the openssl host container of the FIPS library build,
you may pin the DLL file with link flags and dodge this relocation.
Yes. That's what /BASE:x /FIXED does, which causes the problem
(address not available at runtime) which the OP was trying to work
around. We're just back where we started.
The simple fact of the matter is that the FIPS requirements do not
play well with the PE DLL design. Arguably the PE DLL design itself is
at fault (PE relocations also inhibit sharing text pages among
processes, for example), but it is what it is. In 32-bit, address
space is a scarce resource, and OSes make various compromises in
managing it. The real problem is that FIPS 140-2 was written primarily
for hardware and doesn't accommodate software well. And, many have
argued, doesn't really do anything useful anyway - which is no help
whatsoever if your customer is required to have it, or insists on it
anyway.
I don't believe it is a shortcoming of FIPS 140-2 as much as it
is a shortcoming of how the OpenSSL library verifies the hash of
the FIPS blob. Specifically, that the has verification is done
on the runtime-relocated code block, not on it's
unrelocated/normalized form.
If there is a conformant way to change the code ...
And therein lies the rub, because converging on the "incore" scheme we
use was a long and tortuous process that left us with what the CMVP
would accept, not what we preferred. We discovered that the CMVP had
some rather subtle ideological requirements for the integrity digest.
The scheme they are most familiar with is a digest over a shared library
file. Our first thought was just to do a digest over the application
executable file containing the FIPS module (which in many cases would be
a shared library), but that was specifically rejected (see section 2.2
of the OpenSSL FIPS module user guide,
https://www.openssl.org/docs/fips/UserGuide-2.0.pdf).
-Steve M.
Rereading section 2.2 and 2.3 of the UserGuide didn't really give any
reason preventing the creation of an algorithm that checks the required
code and data segment portions (as it does today), but applies a
"normalization" conceptually similar to how signature checking on S/MIME
requires line ending normalization before passing data to the hash
algorithm.
The text did however seem to indicate that the checking code is inside
the blob and thus requires an updated validation in order to be modified.
An alternative approach would be to somehow coach some Windows compiler
into generating truly position-independent code and data for the blob,
however that too would probably require revalidation.
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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
