OpenSSH use of OpenSSL in FIPS Mode

[Steve Marquess]

Jefferson Ogata wrote:
> On 2007-03-06 22:58, Joshua Hill wrote:
>   
>> The central matter that is left unresolved here is this: Is it
>> acceptable to build larger scale FIPS relevant security protocols
>> using the primitives provided by the validated sub-module, _not_ seek
>> an additional validation on this larger scale security functionality,
>> and then sell your IT device into the US Federal setting?
>>
>> I'm fairly certain that the answer here is "no", but it would be
>> interesting to see what CMVP might say on the matter.
>>     
>
> There you're getting into the fundamental issue of how the entire
> concept of FIPS 140-2 validation is broken by design.
>
> What counts as larger-scale security functionality? Is the
> pseudo-terminal driver included, since the data passes through it on the
> way to openssh? What about the VFS code that is used to page the openssl
> shared libraries in? What about the kernel page fault handler? Then
> there's the rest of the kernel--someone could have trojaned it to
> surreptitiously pull all data out of openssl buffers before encryption
> and transmit it to a third party. Or syslogd could be trojaned. And so
> on, ad infinitum.
>
> You have to draw the line somewhere on where the boundary on validation
> is going to lie. And no matter where you draw it, there will be ways to
> subvert the behavior of the validated code. If you follow the line of
> reasoning that the code "outside" the cryptographic module has to be
> validated also, the ultimate conclusion is that you have to validate the
> universe. That would be time-consuming, and certainly exceed NIST's
> resources.
>
> Not offering any answers here, only questions. Sorry.
>   

On the basis of a past interactions with the CMVP I can tell you that 
they are keenly aware that software modules operate in the context of a 
larger computing environment and thus are subject to all the security 
vulnerabilities of that environment. Randy Easter, currently the 
director of the NIST CMVP, once said something along the lines of "with 
software there is no security". They have explicitly stated to me that 
the possibility of malicious attack (i.e., subversion of 
*non-cryptographic* security related functionality) was not a 
significant concern for FIPS 140-2 level 1. They don't attempt to check 
for security flaws like buffer overflows, for example. As I understand 
their perspective FIPS 140-2 isn't broken by design, it just has a scope 
limited to the cryptographic correctness and integrity of the module and 
not the overall security of the operational environment in which the 
module is embedded.

That the CMVP is concerned about *cryptographically* relevant 
functionality I can also attest to personally :-)

This thread has generated some interesting material. I'm going to 
distill it down to a section in the OpenSSL FIPS Object Module User 
Guide and ask my test lab to get it reviewed by the CMVP.

-Steve M.

-- 
Steve Marquess
Veridical Systems, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
301-524-9915 cell
301-831-8447 land/fax
marquess at oss-institute.org