[openssl-users] Clarification on FIPS Tested Configurations

[Nicholas von Waltsleben]

On Fri, Oct 9, 2015 at 3:05 PM, Steve Marquess <marquess at openssl.com> wrote:

> On 10/09/2015 08:13 AM, Nicholas von Waltsleben wrote:
> > Hi
> >
> > I am seeking clarification on what Section 2 (Tested Configurations) of
> > the OpenSSL FIPS 140-2 Security Policy means.  Are these:
> >
> > a) specific configurations that are known to work
> > b) the only configurations permitted by the relevant NIST certifications?
> >
> > I initially believed/assumed that as long as I could compile the OpenSSL
> > FIPS module, without any source changes and following the prescribed
> > steps exactly, I could use it on our platform.  However the more I look
> > at the Security Policy the less sure I am whether that is the case.
>
> Like most things FIPS 140-2 there isn't a simple "bright line" answer.
>
> The platforms (technically "Operational Environments" or "OEs" in
> FIPS-speak) shown in Table 2 of the Security Policy document are the
> platforms that have been formally tested. Only those are directly
> covered by the FIPS 140-2 validation.
>
> However, there are two important considerations to keep in mind. The
> first is the question of what constitutes a match between the OEs listed
> in Table 2 and your target environment of interest. Conventional wisdom
> (not all of which is clearly written, incidentally) holds that any two
> "processor architectures" are equivalent. So for instance any two
> processors implementing the ARMv7 instruction set including NEON are
> equivalent, even though the specific make and mode of that processor (or
> SoC) may differ: AM335x Cortex­A8 and Qualcomm Snapdragon APQ8060 for
> instance. Ditto any two x86 processors that both support AES-NI (Intel
> Xeon 5675 and Intel Core i5­2430M, say). These processor "architectures"
> are shown in parentheses in the third column of Table 2.
>
> The second consideration is something called "user affirmation" which is
> documented in one of the canons of FIPS 140-2 scripture, the
> Implementation Guidance (I.G.) document ("guidance" is FIPS-speak for
> "mandatory requirement"):
> http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf.
>
> User affirmation is documented in section G.5 of the I.G. Basically that
> says that the end user of a validated module can "affirm" use of a
> validation module on a platform (OE) that was not formally tested: "The
> CMVP allows user porting of a validated software, firmware or hybrid
> cryptographic module to a operational environment which was not included
> as part of the validation testing. The validation status is
> maintained in the new operational environment without retesting in the
> new operational environment as long as the porting rules are followed."
> So basically if you can build the OpenSSL FIPS Object Module for your
> platform of interest, exactly as documented in the Security Policy, then
> you can "user affirm" its validity for that platform. Note that means
> *no* modifications at all, not even to the commands used for building
> from the source tarball.
>
> The OpenSSL FIPS module is very portable and the validations (#1747 and
> #2398) include a lot of platforms, so your target of interest is
> probably already covered either directly or via G.5  user affirmation.
> Note that I have heard from some vendors that some of their DoD clients
> won't accept user affirmation, but that's an additional requirement
> imposed by those organizations and not by FIPS 140-2 or the CMVP.
>
> Some platforms of interest may require source code mods, or non-default
> build-time options, in which case user affirmation is not an option. So
> what to do in that case, or when user affirmation isn't accepted by your
> end customer? You can pay to have your platform of interest added to an
> existing validation. That is how the #1747 validation came to include
> over a hundred platforms; over time several dozen sponsors paid for
> those platform tests to add their platforms of specific interest. We're
> still doing "change letter" updates for new platforms though now those
> are being added to a copycat "re-brand" validation, #2398[*].
>
> If you don't want to engage us to add your platform to the existing
> OpenSSL FIPS Object Module validation(s) you can clone it yourself (via
> what is known as an "alternative Scenario 1A/1B" or "re-brand"
> validation). At one point the CMVP appeared to be actively encouraging
> those "re-brand" validations, and now it appears they may be
> discouraging them but as always it's hard to know what they'll do at any
> point in time.
>
> -Steve M.
>
> [*] The tediously ugly details of why this is so can be found at
> http://openssl.com/fips/ransom.html
>
>
>
​Thanks ​for the informative response Steve.  We aren't using anything
exotic in terms of our platform (Ubuntu 12.04 on VMware ESX) but it isn't
an exact match for anything already certified.  If we update to a 3.4
kernel and assume that our customer will be running ESX 5.1 then I believe
we would be covered by #1747.  I will need to get some direction from our
partner regarding the acceptability of 'user affirmation'.

-Nic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151012/c35eb809/attachment.html>