[openssl-users] Static FIPS Library with Address Randomization

[Jakob Bohm]

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 at openssl.org] On Behalf
>>>> Of William A Rowe Jr
>>>> Sent: Monday, March 20, 2017 20:59
>>>> To: openssl-users at openssl.org
>>>> Subject: Re: [openssl-users] 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