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
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
