[Openswan dev] Openswan + FIPS thoughts

[David McCullough]

Jivin Paul Wouters lays it down ...
> On Tue, 30 Oct 2007, David McCullough wrote:
> 
> > We are just starting out on a FIPS certification for some of our
> > products,  and they will include Openswan.  So far we can see no
> > problems with getting the certification,  but we are interested in some
> > feedback on the changes we need to make to get this through.
> 
> We have had inquieries in the past. Usually couped with "openssl is
> already paid for with FIPS, and so is NETKEY, can we change pluto to
> only use openssl with NETKEY".

It's not paid for, everyone needs to certify their version ...

The difference is that is has been certified and is using FIPS approved
algs etc.

> > We are considering two possible approaches:
> >
> > 	1) Replace all the libgmp/crypto code in Openswan user space to use
> > 	   libssl/openssl exclusively.  This will mean we have a single
> > 	   point of testing/implementation for FIPS.  It also means that
> > 	   OpenSwan will continue to use OCF for user space as appropriate,
> > 	   but can also take advantage of the many other openssl engines and
> > 	   accelerators.
> 
> We found that hw accelerators for userland was hardly worth it (and at
> times slower then using hardware)

Yes,  know all about that,  but you don't need to use them.

The thing is that on platforms like Via/Geode and so on,  the openssl
engine doesn't have to call into the kernel.  A lot of CPU manufacturers
also accelerate openssl first which can be useful (depending on the
platform).

Seemed like a nice side affect,  and since I though you guys had already
included the OCF accelerations into pluto,  this actually seems cleaner
IMO.

> > 	2) The second,  perhaps not so pretty solution,  is to hook
> > 	   everything in openswan userspace as has been done already for
> > 	   OCF, but to do it for everything that FIPS cares about.
> >
> > I am not sure of the history here,  so perhaps there is a reason why it
> > should or shouldn't be done this way or that.
> 
> Part is probably history (openssl didnt have the functionality needed).
> Part is bloat (openssl is huge)

No arguments on that one,  though it is also hard to produce a useful
platform without it in some form.

> Part of it was security (openssl is vulnerable on a weekly basis to something)

Which is also a good thing right ?  More eye's and faster fixes and all
that ?

> While it may satisy FIPS, it might not actually be more secure.

No one who knows there stuff will ever say that FIPS is more secure.
It's more about expected behaviour and being able to test that the
system is indeed producing the expected behaviour.

> > Would switching from libgmp/ouwn crypto to a completely libssl solution
> > for the big num and user space crypto code be attractive to the openswan
> > community ?
> 
> I guess ideally, we could allow either one.

It may not be too much work to allow a compile time switch to select.
I just remember Michael complaining that the OCF changes didn't rip out
all the old crufty crypto.  I figured I would see if this was desired
this time around ;-)

> Michael has more intimate knowledge about the aceleration issues.

The acceleration (if you get it) is only a side benefit at best.  It
seemed like a possible plus to switching to OpenSSL.

Our primary goal is to create a system that will pass FIPS with the minimum
of overheads (boot/runtime tests).  To us this means having one of
everything.  One 3DES implementation, one key gen, one big num lib and
so on.  Since the system will have Openswan, OpenSSL amd other systems,
we are looking to reduce duplication of algs and so on.

Thanks for the comments,

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com