[Swan] FIPS mode

Paul Wouters paul at nohats.ca
Tue Apr 14 17:17:51 EEST 2015

On Tue, 14 Apr 2015, jonetsu wrote:

>> From: "Lennart Sorensen" <lsorense at csclub.uwaterloo.ca>
>> But certainly libreswan does the actual packet encryption either with
>> xfrm or with klips, both in the kernel, which is where it belongs.
> Len, I see from the source that indeed all crypto is through XFRM.

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)

>  And we already mentioned that.  But, the concern is about the FIPS validation.

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.

>  Making a parallel, it was termed recently that re-implementing glibc2's crytpto() for passwords using OpenSSL EVP methods would be a far cry better than submitting the glibc2 crypto source code for FIPS validation.  Following the same approach for the crypto done in the kernel - eg. submitting the kernel's crypto code for FIPS validation would also be something costly in both time and money - I looked around and saw that Strongswan uses a plug-in architecture that allows replacing the kernel crypto by OpenSSL, specifically for the goal of FIPS validation.

How can your system be FIPS certified when your kernel is not FIPS certified?
Running FIPS ceritified applications on a "rogue kernel" will not get
your system FIPS certification :P

> We all know that doing this crypto in user space has a (significant) performance penalty.  OTOH, what if most if not all FIPS-certified systems are known to be slow ?  What if no-one (apart perhaps for Red Hat) has put the kernel code through FIPS validation ?  Do we want to go that way if there's a way to save a significant amount of time and money if possible ?

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.


More information about the Swan mailing list