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 CortexA8 and Qualcomm Snapdragon APQ8060 for instance. Ditto any two x86 processors that both support AES-NI (Intel Xeon 5675 and Intel Core i52430M, 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 marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users