On 03/17/2014 01:45 PM, Jason Schultz wrote: > I've been doing some testing with the latest 2.0 FIPS Object Module I > downloaded and 1.0.1e OpenSSL and have a question. > > > I was wondering what the Software Integrity self-test is designed to > accomplish? It seems like it's to ensure the source code or build > hasn't been tampered with. Out of curiosity, I added a comment line in > the file ...\fips\fips.c in the FIPS module. Also, because I wasn't > sure if the integrity check also validated the OpenSSL library, I added > a comment line to the file ...\crypto\evp\evp_enc.c. I then rebuilt the > FIPS Object Module, and the FIPS Capable OpenSSL according to the User > Guide directions. All of the steps seemed to work. I then started my > application, calling FIPS_mode_set(), expecting a failure because of the > modifications to the source code files and resulting libraries I had > rebuilt. However, the call returned success. > > > Does this make sense to anyone? Am I misinterpreting what the Software > Integrity self-test is supposed to do?
Short answer: the integrity test is vestigial and serves no practical function. Longer answer: You're considering this issue from the software developer/software engineer perspective. FIPS 140-2 has a very different and somewhat incompatible perspective. It helps to understand that alternate reality by realizing that the FIPS 140-2 scripture originated at a time when cryptography was utilized only by government and the military using very specialized dedicated hardware (mechanical devices and discrete component electronics). Today anyone who works with software knows that the best defense against software error and compromise is vigilant maintenance; reporting and fixing bugs promptly. But back in this earlier pre-Internet era FIPS 140-2 was formed around the presumption that 1) a complex design and implementation could be perfected for all time, and 2) the best defense against failure of that perfect implementation was carefully guarding against any changes. Those assumptions are the ideological centerpiece of FIPS 140-2. If you move a capacitor on a circuit board, or replace a gear, you might introduce some subtle change in the behavior of the cryptographic module. So, modification of the validated module was rigidly controlled (what is inside the metal box cannot change). But, when cryptography started to be implemented purely in software on general purpose computers this concept had to be re-interpreted. So the integrity test is supposed to assure that the original perfect construction remains intact (the string of bits comprising the executable code can't change). The fixed hardware design became fixed object code. That concept was extended again with the open source based module validations. For Level 1 validations a run-time environment (compiler and linker) is trusted to generate executable code in a consistent and predictable way from given source code in the same way a processor is trusted to execute given object code in a consistent and predictable way. So the integrity test was extended all the way back to the source code via the "chain of trust". If you follow the requirements of the Security Policy (which you must to claim the result as validated) then you verify the integrity of the original source code distribution, then the interim object code, then the module object code in the calling application. That process is intended to verify the perfection of the original source code. When you modified the source code you violated that "chain of trust" and the result does not qualify as validated. You can't make *any* changes to the source code, even for compelling technical or practical reasons. Today we know that software security is a continuing arms race between attackers and developers, that new vulnerabilities will be discovered in any software of non-trivial complexity, and that meaningful security only comes from aggressively maintaining the software to counter those evolving threats. FIPS 140-2 disagrees, and hence known vulnerabilities remain unaddressed in validated modules (for instance, "Lucky 13" is completely mitigated in OpenSSL proper but could not be fixed in the OpenSSL FIPS module). I've run across some discussions that explain the conceptual framework of FIPS 140-2 better than I can, see: http://blog.cryptographyengineering.com/2012/01/openssl-and-nss-are-fips-140-certified.html also: http://www.mail-archive.com/cryptography%40metzdowd.com/msg06990.html and: https://t.co/7u2uLYOFVS -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.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
