Since OpenSSL is providing source code, whats to prevent a user from modifying the crypto code and regenerating the checksum?
What’s to prevent you claiming you’re using FIPS 140 -1/2 validated stuff and not doing so? An Evil Hacker can always download the code (any software, actually, whether related to FIPS OpenSSL or even any version of OpenSSL or not) and hack out any goodness and hack in badness and falsely claim it is “FIPS 140-1/2 validated”. The FIPS 140-2 validation only applies if the steps documented in the Security Policy are followed. FIPS 140-2 is about establishing a audit trail back to the validated cryptographic module. It requires your willing collusion to work. The point of the audit trail is to guard against accidental use of non-validated code. Deliberate use of non-validated code is, of course, always possible. Distribution of the source code from a validated module, and the question of how the running executable software is derived from that source was discussed at length with NIST/CSE. The long answer is that validity of any validation is predicated on the proper use of the software or
Related Questions
- If a user has a program that calls a subprogram, which is object code only, could the user see statement level statistics on that subprogram if the user makes the source code accessible to PROFILER?
- Since OpenSSL is providing source code, whats to prevent a user from modifying the crypto code and regenerating the checksum?
- How does the user know that a particular block of code is being executed on a coprocessor?
