Bouncy Castle FIPS Issue

[Brent Putman]

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/20210716/b6d7ade2/attachment.htm>