Re: 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
__
OpenSSL Project http://www.openssl.org
Development Mailing List 

Re: heap walk in rand_win.c is quite slow

[Jeffrey Altman]

Suggestion.  Do not wait until you establish your first connection to
call RAND_poll().  Initializae the PRNG as part of the startup of your
app or in a background thread.



> Greetings.
> 
> The first SSL connection in my application was taking some 10 to 16
> seconds to return.  Thereafter, subsequent SSL connections would
> complete and return immediately.
> 
> I eventually traced the culprit to RAND_poll() in rand_win.c.
> Specifically, it was the part of RAND_poll() that walks through the
> list of allocated blocks on the heap(s); this heap walk was consuming
> almost all of those 16 seconds.
> 
> I do have a large application, and there were no doubt several heaps,
> each with many allocated blocks.  I see that there was code in place
> to limit the number of blocks traversed per heap to 50, but there was
> no limit on the number of separate heaps that may be traversed.  In
> fact, it was visiting some 500 blocks total in my case.
> 
> (The limit of 50 blocks per heap was as of version 0.9.6d.  I note
> that by 0.9.7-beta3 someone has upped that limit to 80, worsening my
> problem.)
> 
> Is it really necessary to visit so many blocks?  I put in a quick hack
> to apply the 50-block limit to the total number of blocks, rather than
> per heap; this makes it take maybe 2 to 3 seconds instead, which is
> still pretty slow but at least it's tolerable.  (Apparently the
> heap-walking routines in Win2000 are quite slow.)  I am concerned that
> someone recently felt the need to raise the count to 80, however.
> What affect will capping this number have on the security of my
> transactions?
> 
> Perhaps the limit was originally meant to apply to the total number
> anyway, and this was just an oversight?  It doesn't make a whole lot
> of sense to limit the number of blocks visited per heap, without also
> limiting the number of heaps.
> 
> Do you have any advice?
> 
> Many thanks,
> David
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   [EMAIL PROTECTED]
> Automated List Manager   [EMAIL PROTECTED]
> 


 Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and 
 [EMAIL PROTECTED]   OpenSSL.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

heap walk in rand_win.c is quite slow

[David Rose]

Greetings.

The first SSL connection in my application was taking some 10 to 16
seconds to return.  Thereafter, subsequent SSL connections would
complete and return immediately.

I eventually traced the culprit to RAND_poll() in rand_win.c.
Specifically, it was the part of RAND_poll() that walks through the
list of allocated blocks on the heap(s); this heap walk was consuming
almost all of those 16 seconds.

I do have a large application, and there were no doubt several heaps,
each with many allocated blocks.  I see that there was code in place
to limit the number of blocks traversed per heap to 50, but there was
no limit on the number of separate heaps that may be traversed.  In
fact, it was visiting some 500 blocks total in my case.

(The limit of 50 blocks per heap was as of version 0.9.6d.  I note
that by 0.9.7-beta3 someone has upped that limit to 80, worsening my
problem.)

Is it really necessary to visit so many blocks?  I put in a quick hack
to apply the 50-block limit to the total number of blocks, rather than
per heap; this makes it take maybe 2 to 3 seconds instead, which is
still pretty slow but at least it's tolerable.  (Apparently the
heap-walking routines in Win2000 are quite slow.)  I am concerned that
someone recently felt the need to raise the count to 80, however.
What affect will capping this number have on the security of my
transactions?

Perhaps the limit was originally meant to apply to the total number
anyway, and this was just an oversight?  It doesn't make a whole lot
of sense to limit the number of blocks visited per heap, without also
limiting the number of heaps.

Do you have any advice?

Many thanks,
David
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: 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:  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
__
OpenSSL Project 

Re: FIPS 140-2 certification

[Ben Laurie]

Nathan Bardsley wrote:
> Hello everyone!
> 
> I work for a company that uses OpenSSH/OpenSSL to remotely support 
> systems we've sold.  Since some of our clients are US Dept. of Defense 
> hospitals, our access to these servers needs to comply with a whole 
> range of requirements and standards.  At this point it's looking like 
> the SSH daemon needs to be FIPS 140-2 compliant, and the only package 
> that is certified is F-Secure.
> 
> The other option is for CliniComp to sponser getting OpenSSH/OpenSSL 
> through the certification process, and that's what I'm exploring.
> 
> I'd really appreciate knowing what the core developers think about this, 
> and how willing they would be to assisting in the process.  I know there 
> will need to be a fair amount of documentation, and there is no 
> subsitute for first-hand knowledge.  Also, it seems pretty clear that at 
> least some code changes will be needed including self-tests, a new prng, 
> and work in the key generation & validation modules.
> 
> While we (CliniComp) do have some resources including technical writers 
> and programmers, we certainly do not have the expertise in cryptography 
> to just do it all ourselves.  And if this does happen, part of the point 
> would be for the necessary changes to be rolled back into the standard 
> package.
> 
> Please understand that right now I'm just exploring possibilities, but 
> the other option for us is to spend a lot of money on F-Secure licenses.
> 
> I would very much appreciate hearing your thoughts and from anyone else 
> interested in making this happen.

I'm interested, and would certainly support it. Of course, any changes 
made would have to fit in with our general view of the world, but unless 
FIPS 140-2 is completely broken I don't see why that would be a problem.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]