Issues in using OpenSAML 4.x in FIPS compliant applications

[Paul Henson]

On 8/17/2023 5:57 PM, Brent Putman via dev wrote:

> I currently personally know nothing of FIPS compliance, so the concrete 
> requirements here are just a mystery to me at this point. But in general:

I am certainly no expert in the area, but "FIPS" stands for "Federal 
Information Processing Standards", and are basically definitions and 
standards that must be met by federal government agencies and some 
contractors working with the federal government:

https://www.sdxcentral.com/security/definitions/data-security-regulations/what-does-mean-fips-compliant/

One of the areas covered by FIPS is cryptography, for example, openssl 
has a FIPS compliant module:

https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282


To be considered FIPS compliant, a given software library implementing 
cryptography needs to be submitted to NIST for review and certification. 
The certification for Bouncy Castle can be found here:

https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/3514


The problem these people are having is that if they have any Bouncy 
Castle cryptography jars in their class path other than the FIPS one, 
the application might, even inadvertently, utilize an algorithm that has 
not been certified and is not allowed. but the application won't run 
without that jar file, as opensaml has hard dependencies on classes not 
offered by the FIPS jar, only the regular ones.

> If it ever gets to the point of us trying to support FIPS properly, we'd 
> really need to nail down what the actual ask is here

Basically, that there be a mode where opensaml is restricted to only be 
able to use the set of cryptographic algorithms that are allowed by FIPS 
and implemented using a FIPS certified library, and has no dependencies 
in that mode preventing it from being run with solely that jar file in 
the class path.

> enough for FIPS users", etc.  Right now the kludges people are doing are 
> just avoiding runtime errors for things they apparently aren't currently 
> using anyway.

The kludges are being used to allow opensaml to operate using just the 
FIPS certified Bouncy Castle jar file and removing any load/runtime 
dependency on other noncertified cryptography modules.

> But to do it properly, we might actually have to make all of that stuff 
> work with the BC FIPS dependency. As in, they might actually want to 
> use ConcatKDF with ECDH.  Or even EC keys period, which is what most of 
> the ECNamedCurve* and EC5Util dependence is about (consuming and 
> emitting KeyInfo structures).

If you look at the certification for the Bouncy Castle FIPS Java API, 
you will see that while ECDSA is listed, ECDH is not. It doesn't matter 
whether or not they want to use it, they are not allowed to, as Bouncy 
Castle does not provide a FIPS certified algorithm implementing it. If 
it's not in the FIPS jar, it can't be used.

> So, we might have to have separate modules in java-opensaml and 
> elsewhere, for FIPS vs non-FIPS.  We might have to have then different 
> distributions of the IdP. Etc.  Could get complicated.

I don't think you need separate modules per se? Just configuration 
capability such that in "FIPS mode" it doesn't try to load any classes 
or utilize any functionality not provided by the FIPS jar.

> And then there's the fact (that we apparently just had to deal with, 
> again) that the BC folks make completely breaking change Is in any 
> release, i.e. no concept of minor or patch releases ala semantic

Well, that sucks.

-- 
Signet - The Art of Access
https://www.signet.id/