On 04/02/2012 08:14 AM, dave.mclel...@emc.com wrote: > In the draft User Guide for the FIPS Object Module 2.0, the official > validated platforms are shown as Linux and Windows, 32- and 64-bit > architectures, with or without assembler optimizations. The draft > Security Policy mentions only Android 2.2 and HP-UX 11i in section 2: > Tested Configurations, and mentions changes to accommodate > cross-compilation for UCLinux. > > QUESTION: The Security Policy for 1.2.2 specifically spells out the > Linux and Windows validation platforms, but the draft 2.0 document > does not. What does this imply about what platforms will be > considered validated on the 2.0 module?
The upcoming 2.0 module will include roughly 40 separate platforms, either as initially awarded or shortly thereafter via "change letter" modifications. The reason that the draft Security Policy you see only mentions two platforms is that due to the long lead time for CMVP action we submitted the formal paperwork as soon as possible and continued working on the additional platforms (Operational Environments) in parallel. Almost all of those OEs have since been tested and submitted, and are waiting on action by the CAVP (the bureaucracy that handles the algorithm validations that are prerequisites for the FIPS 140-2 validation). > The User's Guide also mentions success with the build on a number of > other Unix platforms, and also uses 'Solaris 10' as an example of a > platform appearing in section 5.5 in the statement of use of the > Module. > > QUESTION: even though Solaris is not shown as a validated platform, > can we, having implemented with (OpenSSL 1.0.1 and FIPS 2.0) safely > make a statement similar to the sample in Section 5.5 on the > non-validated platforms? That is, if we implement additionally on > Solaris, HP, and Linux IA, for example, can we responsibly make the > claim that we are using the validated Module on those platforms? Solaris 10 on SPARCv9 happens to be one of the additional platforms this validation will include. However, assuming it was not (or taking the case of a platform that definitely is not included, Linux on Itanium, say): this is a tricky question. Can a user of the module on platform X claim that usage as validated when platform X does not correspond directly to any Operational Environment? Ok, deep breath... I will give three different answers, a) simple, b) nuanced and conservative, and c) nuanced and liberal. a) The simplistic answer is no. If your target platform does not directly correspond to a validation OE then you need to be very careful about direct claims about validation. b) A more nuanced conservative answer is "it depends". The key concepts here are "code path" and "processor core". The "code path" is the set of object code that is generated when the FIPS module is built from source. That object code maps more or less directly to the C source code when using pure C code (i.e., a "no-asm" build), but for many platforms assembler optimizations are generated by default, resulting in different object code. For instance, for the ARMv7+ processors NEON specific optimizations will be generated for NEON capable build systems (or specified in a cross-compile environment). Three different optimization levels are supported for the x86 processor family: no optimization, SSE2 optimization, and AES-NI+PCLMULQDQ+SSSE3 optimization. If the object code corresponding to a specific level of optimization was not included in any of the validation OEs then that optimization level cannot be considered validated. The "processor core" is the ABI (Application Binary Interface) of the processor ... in this context the set of machine instructions supported by that processor. The OEs processors are (especially of late) specified in tedious detail (e.g., "Qualcomm QSD 8250" and "NVIDIA Tegra 250 T20" instead of "ARMv7"). Clearly the applicability of validations for general purpose software modules would be quite limited if each and every permutation of a processor had to be separately tested. The general consensus appears to be that an OE is applicable to all processors sharing the same fundamental processor capability, e.g. a module validated on one processor with an ARMv4 core is validated on all such processors. Likewise for operating system families, a module validated for Solaris 10, Android 2.2, or Fedora 14 is valid for all similar permutations (kernel upgrades, etc.) of those O/S distributions. One rule of thumb we use in determining whether a given target platform corresponds to a formally tested OE is the "drop-in" test: build the module on the formally tested OE and then copy the resulting FIPS module object file *as-is* to the prospective target platform. If it runs correctly there then it is a good candidate to be considered as validated. By this criteria Linux on IA and HP-UX on PA-RISC would *not* be validated even though the FIPS module will build and run just fine on those platforms (presumably, not having actually tested on those platforms recently). c) Finally a nuanced and hopeful answer is "yes"; if the module builds and runs on your platform then it can probably be claimed as validated by virtue of the "vendor affirmation" or "user affirmation" as described in section G.5 of the Implementation Guidance document (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf). Note G.5 provides a pretty broad latitude for use of a module on "any general purpose computer" and a "compatible single user operating system" (the "single use" part is another can of worms I'll save for later). Note that recompilation to "port" to other platforms is specifically permitted. Normally recompilation would only be done by the vendor of record (OSF for this validation), but for the OpenSSL FIPS Object Module series of validations compilation from source is part of the module installation process. So, if you're willing to "affirm" validation indirectly the validation is applicable to a very broad range of platforms. For marketing reasons some software vendors aren't comfortable with saying that they are indirectly "affirming" validation per I.G. G.5, rather than than directly from the original validation. In some cases minor source code tweaks are necessary to accommodate new platforms, in which case user affirmation is not possible. When vendor affirmation isn't feasible the solution is to obtain a "maintenance letter" or "change letter" modification of the original validation to add the new platform(s) of interest as formally tested OEs. The change letter process is *much* faster and cheaper than a full validation -- usually only a few weeks and a few thousand dollars per platform. By the I.G. G.5 criteria Linux on IA, HP-UX on PA-RISC, etc. could be claimed as validated via user and/or vendor affirmation. Important caveat #1: note in this discussion, windy as it is, I am still glossing over some potential complications. Important caveat #2: FIPS 140-2 is a topic with a lot of unwritten lore and many issues with varying levels of confusion and contention. I have given my best understanding of the situation here but there will surely be some in the FIPS 140-2 community who disagree on one or more points. Important caveat #3: only the CMVP is in a position to make authoritative pronouncements of any kind about FIPS 140-2. In general they will respond to vendor and end user queries, so when in doubt that's probably a better option than trusting some rant you found on the internet. -Steve M. -- 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.net ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
