OpenSSH use of OpenSSL in FIPS Mode
marquess at oss-institute.org
Thu Mar 8 12:11:10 EST 2007
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
> 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.
Veridical Systems, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
marquess at oss-institute.org
More information about the openssh-unix-dev