[Swan] FIPS mode

Paul Wouters paul at nohats.ca
Tue Apr 14 18:07:08 EEST 2015


On Tue, 14 Apr 2015, Lennart Sorensen wrote:

> On Tue, Apr 14, 2015 at 10:17:51AM -0400, Paul Wouters wrote:
>> Just to clarify, XFRM is only used for the IPsec packet encryption, not
>> the IKE packet encryption. IKE is encrypted using the NSS library (which
>> has been FIPS certified in itself on some distributions such as RHEL)
>
> Of course.  But one would hope the majority of the heavy work is
> encrypting data packets, not managing the key exchanges.  I think the
> key exchange overhead is low enough that no one is even bothering to
> try to get it to use hardware accaleration.  Just not worth the bother.

People bothered in the past, and we briefly had support for /dev/crypto
with OCF and Openssl, mostly aimed at the embedded market where it was
worth doing a kernel/userland switch to get access to the kernel crypto
accelerator. Since then, not only have general purpose CPUs gotten more powerful
than the old accelerators, many CPU's now have crypto instructions
available directly in userland. So we removed the /dev/crypto support
(also because it relied on openssl and so you would need both openssl
and nss which is kinda silly)

Doing IKE acceleration indeed does not really make any sense unless it
comes for free (eg within NSS using AES-NI)

>> For RHEL7, Libreswan is currently going through FIPS and Common Criteria
>> certification. In addition, it is going through USGv6 certification and the
>> IKEv2 TAHI test suite.
>
> Which must mean Redhat is also getting at least some of the kernel
> crypto certified.

Yes, the kernel crypto is also getting FIPS validated (and has in the
past as well) and that includes all combinations of supported
architectures and with/without acceleration drivers. It has even
resulted in blacklisting some acceleration modules that did not fully
comply (eg some could only use 128 bit keys and would error on 256)

>> Actually, one thing I do like of strongswan is their support for AF_KEY,
>> outsourcing all IKE crypto to the (FIPS) kernel, so you don't need any
>> certified userland crypto library. And the overhead for doing IKE crypto
>> in the kernel is high on a per-packet level, but since you do about 8
>> IKE packets per hour, speed doesn't matter at all for that part.
>
> Yeah you don't do it for performance reasons.  But I suppose that means
> they have no need for openssl/gnutls/nss in strongswan if you use the
> AF_KEY mode.

Right. Although one of the reasons I like NSS, is that it deals with all
the X.509 / ASN.1 / disk to ram / ram to disk issues. Strongswan has its
own code for that, and that is a lot of custom code. freeswan/openswan
had the X.509 patch that became strongswan, and it generated half the
CVE's we got. I'm very happy libreswan 3.13 will remove the last bit of
that code and outsources all that work to the NSS library. Because an
IKE daemon should not have an ASN.1 parser :)

Paul


More information about the Swan mailing list