Bouncy Castle FIPS Issue

[Brent Putman]

Hi David,

I took a look and unfortunately what you propose won't work, for at 
least 2 reasons.

First (the main and show-stopping technical issue), those 
provider-based algorithms you mention are apparently for the 
KeyAgreement service of the Java security framework. It seems those 
combine the key agreement op with the KDF op all in one go?

That won't work for our design because we're modeling the requirements 
of XML Encryption 1.1 where the KA and KDF ops are conceptually 
completely separate. They are defined separately, have distinct XML 
representations, etc, so one can mix-and-match KA algo and KDF algo.

So in OpenSAML we have distinct KA and KDF interfaces and then various 
impls for each. For example we have interface 
org.opensaml.xmlsec.derivation.KeyDerivation.  The ConcatKDF impl of 
that in question that threw a NoClassDefFoundError with FIPS was our 
org.opensaml.xmlsec.derivation.impl.ConcatKDF, which imports these 
KDF-related classes (along with some needed BC digest classes):

import org.bouncycastle.crypto.agreement.kdf.ConcatenationKDFGenerator;
import org.bouncycastle.crypto.params.KDFParameters;

It was specifically throwing on not finding 
org.bouncycastle.crypto.DerivationParameters, which is the interface 
implemented by the above BC KDFParameters.  For reference that source 
is here:

http://git.shibboleth.net/view/?p=java-opensaml.git;a=blob;f=opensaml-xmlsec-impl/src/main/java/org/opensaml/xmlsec/derivation/impl/ConcatKDF.java;hb=refs/heads/main

By contrast, for PBKDF2 we are using the SecretKeyFactory service with 
the JDK-provided algorithm support for "PBKDF2With*" (completed with 
the appropriate PRF algo ID).  So if the BC provider had a 
SecretKeyFactory impl for ConcatKDF by itself, that would be closer to 
our needs. But....

Second, it's unlikely we could introduce a deployment requirement for 
people to add the BC provider declaratively in java.security and also 
questionable for us to add the BC provider programmatically by 
default.  As a library OpenSAML probably shouldn't muck with people's 
environments like that.

And in XML Encryption 1.1, ConcatKDF is the mandatory-to-implement KDF 
(PBKDF2 is optional).  For that reason it is our default KDF for ECDH, 
and it needs to work out-of-the-box.  So hopefully you can see that 
adding a requirement on configuring a third-party provider would be an 
issue for us.  Our team can discuss further the idea of 
automagically/programmatically adding in BC.  I personally am not a fan 
of the idea.  But unless/until BC has a provider-based impl of the 
ConcatKDF by itself, it's essentially a moot question.

I guess what I would ask about the FIPS version is:  If the provider 
there fundamentally supports ConcatKDF via the KeyAgreement algorithms 
you mention, then why aren't the KDF interfaces/impls there as well?  
Probably they are there but just with different package and/or class 
names, etc?  If they are, then you know, that means the FIPS version 
really isn't a drop-in replacement for the regular library, so it's 
going to be challenging for us as a downstream consumer to overcome that.

Thanks,
Brent



On 7/13/21 10:30 PM, David Hook wrote:
> Hi Brent,
>
> I'd like to suggest that it gets changed to use the BC provider 
> rather than the BC low-level API.
>
> For some reason I can't connect to any of the nabble references, so I 
> can't easily find the source file concerned, but from what I 
> understand V4.1 added support for the ConcatKDF key derivation 
> function with ECDH. When I checked the code this looked like 
> something the BCFIPS provider supports already (and the BC provider) 
> for the JCE. The agreement algorithms ending in CKDF use the concat 
> KDF function.
>
> The following ones are currently available in both providers:
>
> ECCDHWITHSHA1CKDF
> ECCDHWITHSHA256CKDF
> ECCDHWITHSHA384CKDF
> ECCDHWITHSHA512CKDF
>
> I have subscribed to the dev list if you would prefer to continue the 
> discussion there. If you would include the link to the source file 
> either way we should be able to work something out that will work for 
> both providers (as I have commit access to both, you'd hope so!).
>
> Let me know,
>
> Thanks,
>
> David
>
> On 14/7/21 7:17 am, Brent Putman wrote:
>>
>> Hello,
>>
>> Sorry David (Hook) that I didn't get back to you when I returned 
>> from vacation a couple of weeks ago, I unfortunately overlooked that 
>> email todo.
>>
>> I'm interested to hear what you had in mind.  If possible it would 
>> be great to have this discussion over on the Shibboleth/OpenSAML 
>> developers list, so that other members of the team and community can 
>> be aware and participate:
>>
>> https://shibboleth.net/mailman/listinfo/dev
>>
>> Thanks,
>> Brent
>>
>>
>> On 7/9/21 11:54 AM, David Castro wrote:
>>> Brent,
>>>
>>> Just wanted to follow up Re: the following thread on the FIPS issue 
>>> we were having.
>>>
>>> https://shibboleth.1660669.n2.nabble.com/Bouncy-Castle-FIPS-Issue-td7649455.html#a7649653 
>>> <https://shibboleth.1660669.n2.nabble.com/Bouncy-Castle-FIPS-Issue-td7649455.html#a7649653>
>>>
>>> We spoke with David Hook from Bouncy Castle (included in this 
>>> thread) and he had some ideas on resolving the issue. Scott Cantor 
>>> recommended you as the point of contact, but let us know if there 
>>> is someone else we should reach out to.
>>>
>>> We are also available to assist as needed.
>>>
>>> Cheers,
>>> David
>>>
>>> -- 
>>> CONFIDENTIALITY NOTICE: This transmission, and any attachments, may 
>>> contain CONFIDENTIAL, PRIVILEGED or PROPRIETARY information of 
>>> HRworx, LLC (dba Intelliworx) that is protected from disclosure 
>>> under applicable laws. If you are not the intended recipient, any 
>>> disclosure, copying, distribution, or use of any of the information 
>>> contained in or attached to this transmission is STRICTLY 
>>> PROHIBITED. If you have received this communication in error, 
>>> please notify the sender, by reply e-mail, and delete the original 
>>> message with any attachments. Thank you for your cooperation.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20210714/ad9f3ce2/attachment.htm>