Deferred decryption of private key
Description
Environment
Activity
Scott CantorAugust 7, 2018 at 6:23 PM
Some docs added, a bit rough but we'll see.
Scott CantorJuly 31, 2018 at 9:12 PM
Committed a working flow that supports unlocking any number of secret and private keys and relies on some changes to the DataSealer code to support deferred population of the default key.
The most invasive step is the need to move the Credential factory bean(s) to inject private keys into out of credentials.xml and into the root Spring context so the flow can get at them but it's not that hard to do.
A default view template is included but I included the Spring config for the flow conditionally so it can be left out for most deployers that aren't using the feature.
Right now the flow can be re-run over and over and just repeats the unlocks each time, and I don't think that breaks anything. The ideal would be some kind of global flag recording the unlock but I haven't come up with a way to do that yet short of creating a custom Java object to track a simple boolean.
Ian YoungJuly 30, 2018 at 12:56 PMEdited
Isn't the network round trip alone more than 2ms? That's the constraining factor, I would think, particularly coming from outside their network.
2ms is what I got from my test, which was MDQ generation for about 8000 elements. I subtracted the time to generate unsigned documents from the time to generate signed documents, then divided by 8000. I suppose it's possible that I am getting some latency hiding and the actual figure is a bit higher.
I have only tried this within their network. I don't know if they even support direct access to the HSM from elsewhere.
Scott CantorJuly 26, 2018 at 11:53 PM
For completeness this has to address the client session data key as well since cracking that would allow forging a session and the same impersonation risks, though its much easier to recover from with a flush of old keys.
I was able to make some simple mods that allow the IdP to start up and run while access to the DataSealer key fails and those operations just throw. Lots of warnings in the log but pretty reasonably behavior.
The next step is to come up with an unlocking flow that prompts for some set of passwords and then sets the passwords into the key strategy bean for the secret key and then producing unlocked private key(s) to inject into globally-accessibly credential beans.
Scott CantorJuly 26, 2018 at 1:08 PM
Isn't the network round trip alone more than 2ms? That's the constraining factor, I would think, particularly coming from outside their network.
My guesstimates of the current software overhead for signing was that best case would be about break even factoring the network in, which is not bad, but doesn't account for the risk of occasional drops and such that could kill reliability.
I don't think we have a very practical story for protecting private keys right now, because passwords on disk are just stupid (always) and don't prevent the "backup admin gets the key" problem that my auditors have rightly been dinging me on.
The party line is an HSM I guess, but PKCS11 is literally the worst, and I don't think there are any performant options in that space that don't cost a fortune. Amazon's is 30K each. And I can't see how a network hop to sign could be viable anyway, so I suspect this is geared to other use cases anyway.
PAM and vault-type solutions are a little better since it might be harder for the insider to get access to the vault with whatever password unlocks that, but it's really just turtle transport to me, and it adds yet another online system to get an IdP running.
I think I'd like a model where unattended restarts are just not a thing (I have never once had to do this in 20 years running SSO servers), and the password is supplied at runtime.
What I'm envisioning is a wrapper for BasicX509Credential that "defers" its initialization from the bean properties and if you access it before it's unlocked, it just fails gracefully, so the IdP would be working but non-functional during signing or decryption.
An admin flow could be written that prompts for the decryption password(s) and feeds those into a global bean and then that bean would be ref'd into the wrapper Credential and it would be able to unlock the underlying objects and go on with life. The admin flow should be usable with real authentication because the login layer doesn't generally need the keys to work, so it could even be MFA-protected to get in and feed in the unlock code.
This is really OSU work, so I won't ding project time for it if I do it.