>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