<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi David,<br>
</p>
<p>Since sending the below, I also had a couple of small epiphanies.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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.)<br>
</p>
<p>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.</p>
<p>Thanks,<br>
Brent</p>
<p> <br>
</p>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 7/15/21 7:46 PM, Brent Putman wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c3b64fba-bd17-1b52-f904-087af21a7b84@georgetown.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>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!).</p>
<p>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.</p>
<p>Thanks,<br>
Brent</p>
<br>
</blockquote>
</body>
</html>