OpenSSH use of OpenSSL in FIPS Mode

[Stan Kladko]

>From our experience working on FIPS 140-2 conformance testing of IT products 
when a decision is made on whether a particular IT solution is FIPS 140-2 
compliant multiple factors need to be taken into account, including the FIPS 
Pub 140-2 standard, FIPS 140-2 Derived Test Requirements, CMVP FAQ and 
Implementation Guidance. The ultimate authority in this process belongs to 
the CMVP. The CMVP provides its current interpretations and guidelines as to 
the intepretation of the  FIPS 140-2 standard and the conformance 
testing/validation process on its public web site 
http://csrc.nist.gov/cryptval/

In particular, the official CMVP FAQ available at

http://csrc.nist.gov/cryptval/140-1/CMVPFAQ.pdf

discusses incorporation of another vendor's cryptographic modules in a 
subsection of Section 2.2.1 entitled "Can I incorporate another vendor's 
validated cryptographic module". In particular, the following is specified:

"
Yes. A cryptographic module that has already been issued a FIPS 140-1 or 
FIPS 140-2 validation certificate may be incorporated or embedded into 
another product. The new product may reference the FIPS 140-1 or FIPS 140-2 
validated cryptographic module so long as the new product does not alter the 
original validated cryptographic module. A product which uses an embedded 
validated cryptographic module cannot claim itself to be validated; only 
that it utilizes an embedded validated cryptographic module.
There is no assurance that a product is correctly utilizing an embedded 
validated cryptographic module - this is outside the scope of the FIPS 140-1 
or FIPS 140-2 validation. "

Note that the CMVP FAQ does specify that a FIPS 140-1/2 validated module may 
be incorporated into another  product. It then specifies that making a 
decision on whether a product is correctly utilizing an embedded module is 
outside of the scope of the FIPS 140-1 or FIPS 140-2 validation.

A subsection of Section 2.1 of the CMVP FAQ entitled

"A vendor is selling me a crypto solution - what should I ask?"

specifies in particular:

"Verify with the vendor that the application or product that is being 
offered is either a validated cryptographic module itself (e.g. VPN, 
SmartCard, etc) or the application or product uses an embedded validated 
cryptographic module (toolkit, etc). Ask the vendor to supply a signed 
letter stating their application, product or module is a validated module or 
incorporates a validated module, the module provides all the cryptographic 
services in the solution, and reference the modules validation certificate 
number."

Note that it is specified that the validated module shall provide "all the 
cryptographic services in the solution". A typical IT solution may provide a 
variety of services. From such a set of services all the cryptographic 
services shall be provided by a validated cryptographic module.

A typical network protocol, such as IPSec/IKE, TLS, SSH, S-MIME or 802.11 
protocol family may provide a complex variety of services. Some of such 
services may have cryptographic nature and utilize Approved or allowed for 
use cryptographic algorithms, such as encryption, decryption, signatures, 
hashes, message digests and others. Other services provided by a network 
protocol may be of non-cryptographic nature, such as packet routing, packet 
assembly/disassembly, defragmentation, radio and link layer communications, 
firewalling, network address translation, address resolution, quality of 
service, re-transmission and others. While the ultimate verdict for a 
particular solution belongs to the CMVP, it is generically logical to assume 
that non-cryptographic services of a particular network protocol or a set of 
protocols may be implemented outside of a validated cryptographic module. 
This is also logical having in mind that in many cases non-cryptographic 
services of a particular protocol may be delegated to other devices in the 
IT solution. For instance, in some wireless LAN access systems an 
implementation of the 802.11 protocol set is provided jointly by a wireless 
access switch and a wireless access point, where the wireless access point 
may provide non-cryptographic services of the 802.11 protocol set such as 
radio transmissions, frequency and signal strength control, initial wireless 
client association and others. Another widely used example is a web server 
offloading cryptographic functionality of the HTTPS/TLS protocol to a FIPS 
140-2 validated cryptographic accelerator card (many such cards are 
available on the market).

It is then also important to consider industry-wide interpretation patterns 
and precedents in this field. After performing a review of the FIPS 140-2 
validated products list http://csrc.nist.gov/cryptval/140-1/140val-all.htm 
one may conclude that implementing non-cryptographic services of a 
particular network protocol outside of a validated cryptoraphic module can 
in many cases be considered as an industry trend. There are multiple 
examples which illustrate such a trend. For illustration purposes only we 
can take a look at the example of the Microsoft Kernel Module

http://csrc.nist.gov/cryptval/140-1/140sp/140sp241.pdf

Here I would like to re-iterate that there are many other modules which 
follow a similar trend, the module is just one example out of many. The 
analysis here is generic, applies to a large number of validated modules, 
and is not intended to make any specific statements as to the validation of 
this particular module.

As specified by the vendor, the Kernel Module is used by the vendor 
impelementation of the IPSec/IKE protocol

http://www.microsoft.com/technet/archive/security/topics/issues/fipseval.mspx?mfr=true

In particular it is stated that

"Both IPSEC and EFS in Windows 2000, XP, and Server 2003 use the FIPS-140-1 
or FIPS 140-2 (as appropriate) evaluated Kernel Mode Cryptographic Module to 
encrypt the traffic packet data and file contents respectively if configured 
appropriately with the selections of FIPS compliant algorithms."

A review of the Kernel Module Security Policy then shows that the module's 
services are specified as services performing cryptographic algorithms 
supported by IPSec/IKE(such as encryption/decryption and key agreement) and 
not as providing a full IPSec/IKE protocol impelementation. This could again 
serve as an illustration of the fact that non-cryptographic services of a 
particular protocol are in many cases implemented outside of a cryptographic 
module. A similar analysis could be performed for other protocols specified 
in

http://www.microsoft.com/technet/archive/security/topics/issues/fipseval.mspx?mfr=true

such as S/MIME (used in Outlook), TLS (used in Explorer), Remote Desktop 
Protocol and Encrypting File System.

While the example discussed here does not directly consider to the SSH 
protocol, it bears significant degree of similarity to the question 
considered in this e-mail thread. Other examples can be discussed by 
analyzing the list of historically validated products 
http://csrc.nist.gov/cryptval/140-1/140val-all.htm .

To conclude, both the historical perspective and the current CMVP guidance 
point to a possibility of non-cryptographic services in an IT solution being 
impemented outside of a validated cryptographic module. We are not aware of 
any CMVP regulations explicitely denying use of embedded validated 
cryptographic modules to satisfy the requirements of FIPS 140-2 statement, 
provided that the set of conditions specified in the CMVP FAQ and other 
relevant documentation is satisfied. With this in mind, the ultimate 
decision for a particular product/protocol belongs to the CMVP and the 
analysis presented in this e-mail can serve for discussion purposes only.

With best regards,

Stan Kladko, Aspect Labs FIPS 140-2 Lab
www.aspectlabs.com


>> > Does it much matter?

>Bill Colvin responded:
> Yes it definitely does matter, particularly to government agencies (and
> more and more businesses) that are required to use FIPS certified crypto
> algorithms.
[...]
> The whole point behind getting FIPS certification for the OpenSSL source
> library is so that other open source applications (e.g. Apache or
> OpenSSH) can take advantage of it and provide applications that are only
> using FIPS Certified algorithms for those users that require it in their
> environments.

>My point is that the OpenSSL validation does not accomplish the generally
>desired end. In order for a US federal agency to use hardware or
>software to protect certain types of information, all the relevant crypto
>functionality of that hardware or software needs to be covered by a FIPS
>140 certificate. The crypto functionality explicitly includes _all_
>key establishment functionality, including the implementation of the
>key establishment and data protection protocols (e.g., TLS and SSHv2).

The portion of the OpenSSL library that was actually evaluated only
include the cryptographic algorithms, and a bit of additional logic.

Thus, any product that includes the FIPS validated OpenSSL component,
and additionally includes some other crypto functionality (for example,
an implementation of the TLS protocol, the SSHv2 protocol, or really
almost anything else that is likely to be built on top of this particular
validated module) will need to go through its own separate FIPS 140
validation process.

Josh