As luck would have it, I've been recently tasked to find a substitute for the Hardware Security Module that, for a handful of reasons, would no longer be able to serve us.
What is a HSM?
HSMs are server appliances, built on top of PKCS #11 in order to take advantage of the cryptographic functions, while maintaining a high level of security for the keys that it holds. The authentication, encryption, decryption, signing and all manner of connections to it are logged. They usually come with cryptographic security tokens that make sure you need to be physically present, to even perform any sensitive operation like reboots.
Sitting on the application server is an agent that would already have had a certificate exchange with the HSM appliance. The application need only to liaise with this agent, that will handle the communication with the HSM server.
The hunt
It would have been an easy job, had we only require asymmetric keys. Any old JKS, or PKCS #12 archive (for better compatibility outside of Java) stored within the application server would work. Except that our application require use of symmetric keys. The problem is, most keystores (a concept mostly within Java) only support private key and certificate pairs. They cannot handle storing secret keys.
Enter JCEKS. The Java Cryptographic Extension Key Store can carry private and secret keys alike. The next closest thing is from Bouncy Castle, with their BKS/UBER. A quick browse-through using KeyStore Explorer should suffice to show you their differences from JKS and PKCS #12. But I did take a little bit further to confirm that both Oracle and IBM variety of the JRE does indeed not support generating secret keys into PKCS #12 keystores, just because this claimed it possible. The runtime throws an exception because you'd have to pass in a null for the certificate, when PKCS #12 expects a certificate.
Any answers?
The valiant effort of OpenDNSSEC with providing a SoftHSM, proved too complicated beyond my comprehension. Whereas an Italian job - j4sign - requires an actual smart card as part of their recipe.
Somebody did suggest to encrypt the secret key with an asymmetric key kept in a keystore, and store it alongside in the filesystem. I see where he's coming from, but I'd feel naked and exposed not containing the key within the archive. It's plausible; just not ideal.
So what do?
I'm sticking with JCEKS for the time being. My counterparts working on C++ may need to put in some effort, while we sort this out. But to the best of my abilities, I've tried providing a wrapper JAR (that basically behaves like the HSM agent) for them to take advantage of the JCE keystore. It's still a work in progress, so if I can't convince them to make it work, we'll need to come up with an alternative, and fast.
The journey continues!
If you have any inkling of all these shenanigans, hit me up and let me know your thoughts.
