FIPS 140-2 certification

[Joshua Hill]

On Fri, Sep 27, 2002 at 07:10:18PM -0500, Ben Lindstrom wrote:
> FIPS 140 is linked to C2 security from the looks of it.   And from my
> skimming it looks like  OpenSSL would need to get NIST approval for their
> general crypto, their digital signatures, and more than likely thier MAC
> code.

FIPS 140-2 (http://csrc.nist.gov/cryptval/140-2.htm) doesn't directly
relate to TCSEC C2, though there are some of the TCSEC C2 requirements
that are folded into the CAPP Common Criteria Protection Profile, which
is referenced by FIPS 140-2.

FIPS 140 allows the vendor to establish the bounds of the cryptographic
boundary.  One possible place to establish these bounds is the OpenSSL
library, but by doing this, you would exclude the logic that governs the
key agreement protocol, user authentication, cryptographic configuration,
etc, that is used by OpenSSH, which is against the spirit of FIPS 140,
if not the letter of the standard.

> As for OpenSSH, there is very sketchy.  If I read it correctly, their
> would perfer you do crypto keys via a cryptocard, securid card, etc.  

They want you to generate keys (and inputs to things that are used
to establish/agree apon keys) using an approved PRNG.  At this point,
the PRNG would need to either be an implementation of the ANSI X9.31
appendix C PRNG (which is TDES based) or the FIPS 186-2 appendix 3 PRNG
(which is either SHA based, or DES based).

This requirement should not be confused with the FIPS 140-2 statistical
tests, which are run on an already evaluated/validated PRNG design to
make sure that it isn't malfunctioning.

> I'd have to see a results of an audit to make any real comments on it, but
> at glance I'm not sure FIPS 140 has very much affect on OpenSSH.  FIPS 140
> seems to be a 'system level' document not a single 'software level'.  

The OpenSSH product is the sort of thing that is FIPS certified.  FIPS is
somewhat hardware-centric, but there are quite a few software modules.
In addition, NIST has been trying to generally make the FIPS 140 standard
more software-friendly (the physical security section can be marked not
applicable for software only modules, for instance). For the most part,
they have succeeded in making it obtainable.

The one area that still poses a problem for real modules pursuing level
1 certification is the operating environment section.  At level 1,
FIPS 140-2 doesn't require any particular operating system to be used,
but it does require a series of somewhat draconian restrictions to be
placed on the operating system.  (the OS must be in Single User Mode,
for instance)  These restrictions have historically made it so that
vendors are not interested in pursuing FIPS 140 level 1 certification
on software modules that run on UNIXish systems.

This (somewhat perversely) makes it somewhat more reasonable to obtain
FIPS 140-2 level 2 in the operating environment section.  In order to
get level 2 in this area, the vendor must use a common criteria EAL2
(or equivalent) rated operating system, evaluated to one of a set of
approved protection profiles.

Getting a common criteria rating on something as large as an operating
system is a rather long, intensive (costly) process, but fortunately,
SUN has already done this with Solaris 8.

So, the easiest way to proceed is probably to do the evaluation on a
common criteria compliant install of Solaris 8.

> SSH
> protocol itself cares nothing about a lot of the stuff in the docs, but as
> a system admin you would care your OS supports it.

The SSH protocol can't go through FIPS 140-2 evaluation, only a particular
implementation of the protocol.  You can provide a set of policy documents
to address items that are somewhat out of the control of your software.

> The other thing that sticks out in the document is their repeated request
> for some form of 'hardware' crypto.  Which would by-pass (correct me if
> I'm wrong someone on the OpenSSL List) most of the need to certify most of
> the algorthms.

FIPS 140 doesn't require hardware implementations of any algorithm.

> OpenSSH (In theory) should deploy no internal encryption code.  I believe
> we break the rule for AES only because at that time OpenSSL did not
> support it (they do now).   We depend on OpenSSL for all crypto work (that
> way we can support hardware crypto).

A FIPS module is required to perform self-tests in order to verify that
its crypto functionality is working correctly.  These tests must be run
each time the module is started.

If the OpenSSH program is to be certified, it needs to do these tests.
If the OpenSSL library accomplishes them (which I do not believe it does)
then nothing else needs to happen.  More likely, however, the various
OpenSSH commands would need to test all the cryptographic primitives
it uses.

				Josh