FIPS 140-2 certification

[Ben Lindstrom]

On Fri, 27 Sep 2002, Nathan Bardsley wrote:

> Ben Lindstrom wrote:
> > Where are theses 'DIPS 140-2' requirements?  If they are anything like the
> > other military requirements they are impratical and insane (yes I've had
> > some time in the area.  Not my idea of fun =).
>
> This: <http://csrc.nist.gov/cryptval/> is the URL at NIST, I'm just
> getting started at digging into this, and so any answers I might give
> you today are probably not the answers you want.  I don't get the sense
> that the requirements are insane, but yeah, it's certainly possible some
> of them will oppose the OpenBSD/SSH/SSL philosphies.  For the most part,
> it seems that FIPS 140 is (one of) the lowest standards for "sensitive
> but unclassified" information.  And pretty soon, if not already, most
> crypto software used in DoD related projects will need to certified.
>

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.

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.  And
the ability to support -C none for testing on wire (I think you can get
away without it).

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'.  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.

I'm surprised that you are using IRIX.  I would not have thought IRIX
would have gotten FIPS rating.  AIX or Solaris Trusted would not have
surprised me.  Guess I'll have to have a chat with a buddy over there. =)

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.

> > We have a regess/ section in the current tree.
> >
> > What is the issue with prng?  You really should be using kernel level
> > devices.  prngd and built-in prng should be a last resort.  Besides, I
> > bet our prng could easily get certified by NIST.  It is a more sane
> > implementation than some of the NIST certified stuff at my work.=)
>
> I was trying to give you guys a broad overview of what I've gathered so
> far, so please don't take anything as a criticism.  I spoke with an
> engineer at one of the labs could do the testing, and that's where that
> list of issues came from -- a very brief conversation about whether or
> not I was crazy to try this.
>

I'm not taking it as a criticism.  Just giving my person belief.  The NIST
randomization test is pretty basic.  The idea behind the builtin PRNG or
PRNGD should easily pass it without too much problems.  However for either
case it really would depend on what programs you allow it to grab entropy
from.

I don't have a crypto PCI card, but with one of those in a box lacking
kernel level /dev/random.  Does OpenSSL always seed itself?  If so it
removes the need for our prng.

Otherwise, my suggestion is NIST must have certified a random number
generator card.  Write your own 'ssh-prng-helper' that uses that card
instead of our code.  =)  That is why it was rewritten that way for
customized prng generation.

> The self-test requirement is (I think) on module loading, a sort of
> software POST.  The prng issue is (once again, I think) that your prng
> isn't certified.  (=My= issue with prngs is IRIX, and believe me I know
> that it's my problem =).  There is not a list of what the specific
> problems and issues are yet, and much depends on exactly how the "sytem"
> to be certified is defined: what exactly is the relationship between
> OpenSSH and OpenSSL during the testing process?  What platform is the
> testing done on?  What codebase snapshot is used?  What is the
> configuration to be certified?
>

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).

BTW.. I'm not turning my nose up at the idea.  Just a bit leary.  I've
spent enough time reading C2 and seeing implemention of it to know how
insanely complex it can be for almost no real gain.  FIPS 140 looks a lot
more sane, but it seems to be targeting the whole machine.

If your company goes ahead and does a prelimitary test to see how
compliant the code is.  I'm sure OpenSSL and OpenSSH project would be
interested in the outcome.  I can't say that it will be adopted unless
they are reasonable things.

- Ben