Bouncy Castle FIPS Issue

[David Hook]

Hi Brent,

It would improve things.

One other thing that might be worth looking at is adopting an interface
approach for calling out to cryptographic services. We've done this for
the PKIX APIs for BC for both Java and C#, it's meant the functional
component of the CMS API is not only provider independent but also JCE
independent. The XML definitions do seem very similar to CMS so it might
be worth it. Further down the track this might also offer a way to break
the current dependency.

Regards,

David

On 17/7/21 2:03 am, Brent Putman wrote:
>
> Hi David,
>
> Since sending the below, I also had a couple of small epiphanies.
>
> First, regarding HSM and private keys:  XML Encryption only defines
> and supports ECDH in ephemeral-static mode.  So at least on our IdP
> side, as the (typically) originator/encrypting party there is no
> long-term private key since that's the ephemeral key pair side. 
> (Discounting the extremely uncommon case of EncryptedIDs in inbound
> messages to the IdP.)  Since it's just one time use, the issues around
> leakage of ephemeral private key info via the ephemeral agreement
> secret are close to non-existent there, I think.
>
> To the extent that there is any issue, it would be isolated to the
> recipient/decrypting party side, which in SAML is typically the SP
> side of the exchange. We don't currently have such a Java product,
> although we are currently working on a Java-based re-implementation of
> our SAML SP, so it would come up there.
>
> Second, back to the practical issue here as originally reported:  I
> think there is a very simple solution to the issue of the missing
> classes in the FIPS jar.  I believe we can simply suppress via an
> optional system prop etc the instantiation of the OpenSAML class in
> the config bootstrap which references those missing BC classes,
> thereby avoiding the issue.  It would mean such a deployment could not
> do ECDH with ConcatKDF (could use PBKDF2 though), but would at least
> allow the IdP to otherwise work correctly with the BC FIPS jar. (And
> lack of ECDH is practically not an issue - we aren't aware of any
> current SAML SP implementations which even support ECDH.)
>
> The coding for that would be very simple.  We expect to put out an
> OpenSAML and IdP patch release soon, so unless there's a problem with
> that approach we can likely include in that release.
>
> Thanks,
> Brent
>
>  
>
>
> On 7/15/21 7:46 PM, Brent Putman wrote:
>>
>> Regarding HSMs and leaking info:  From a practical standpoint I think
>> there's very little real world concern about the ephemeral agreement
>> secret being handled in memory on the host. It's not stored
>> persistently, but it is there as a local method var, so will exist on
>> the heap prior to GC.  But even more practically, we simply don't
>> target the kind of high security use case for HSMs.  We're not sure
>> it's even possible to actually use an HSM with say the Shib IdP, and
>> probably zero users actually trying to do this via PKCS#11. (If
>> someone is please let us know!).
>>
>> So realistically private keys are loaded from disk, they are
>> in-memory, and that's where the real world risk is.  And so any
>> concern about the ephemeral agreement secret is trivial and moot by
>> comparison. That might not be "great" in some absolute sense, but
>> it's simply the reality of modern online services, and we're just
>> part of that world.
>>
>> Thanks,
>> Brent
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20210717/105c54b7/attachment-0001.htm>