I already tried out the DKEK mechanism for generating a backup of a key on another HSM. Nevertheless, we are facing some problems with our key policy: What if a Key Custodian of a n-of-m DKEK share leaves? What if n key custodians leave? Isn’t then the n-of-m scheme “theoretically” broken? As far as I know, I can’t resetup a DKEK. So I would have to decrypt every single private key ([1]) and reimport it on another HSM with different DKEK and a new set of m key custodians.
I stumbled over another key domain, called XKEK. But I didn’t find any help on this. How to use XKEK? Could it be helpful for above scenarios? I think about a scenario where I can setup another HSM with a different DKEK, but exchange keys between them by XKEK. Would that be a possible solution?
Where to find information about XKEK? Is there a “How-to” about XKEK?
I am afraid, you cannot organize the key recovery schema the way you want, based only on shares and HSM devices. One possible solution, involves 3-rd party device. I can’t call it a perfect solution, it is just some solution that might show a different point of view to the problem and its solution. You need a device like Raspberry Pi, stored safely (friend from Ukraine constructed self-destructive Pi case), HSM attached to it, RS232 for servicing the I/O flow. The signing key is on the HSM, the PIN is in the Pi’s memory. Every hash to sign comes through RS232, along with M of N valid signatures (in my case they are in p7s format). On the Pi you have an application that checks those signatures and decides whether to sign or not the hash, using the key in HSM (in my case the application is in Python 3.6, but once you operate a device like Pi, you can write it in Java or C++). CRL list is maintained on the Pi, so no hash signed by a revoked X.509 certificate will be directed to HSM for signing. Copy of the signing key installed on HSM should be kept in KRA system (we used RHCS).
I definitely came across the XKEK Key domain for the HSM. There is some documentation in the SmartCard-HSM manual on the Cardcontact Devnet, but it’s not very detailed. Maybe @sc-hsm could give me some hint?
If I see it right, one generates all required shares and stores them in an encrypted, safe offline environment. Then imports the shares to the devices, new or old ones, whenever needed. That means of course, that there is one extra place that requiring protection.
These DKEK shares are stored in a secure place (keepass, printed in a bank safe, etc). Then multiple people and multiple passwords are required to initialize the HSM (or to calculate the unencrypted DKEK share).
