[Nitrokey HSM] DKEK, CA High Availability and security

I consider to use two (or more) HSM 2 for CA root/intermediate ECC keys. As I understood, I should initiate 1-st HSM2 with DKEK, generate ECC key, than backup it as wrapped object, and restore to 2-nd HSM2.

My concern is that in this scenerio I need only one export of wrapped key, by I MUST initiate 1st HSM (and 2-nd too!) in the way that anybody with Physical access can export wrapped key too. Of course in practice the BAD can export, but need key shares (pbe files/password) to restore ECC. But key shares / pbe files with password is week, one factor security (something you know) in opposite to HSM2 (strong, two factor security - something you know - PIN, and something you have: Nitrokey HSM2).
If I generate key shares / pbe files, I can be sure that this not leak, buceause we cannot totally trust our x86 mainboards, x86 CPUS, servers/workstation.

Is any way - now or will be in the future (next firmware upgrade, next, let’s say HSM 3 device), to DISABLE (till next initialization) DKEK on 1-st HSM 2 after backup and on 2-nd HSM after restrore?

Is any plane in the future to arrange DKEK backup/restore in a such way that there will be impossible to reconstruct backuped ECC/RSA key outside of HSM2? For instance as follows:

  • each HSM2 has secret (AES), private, SECRET, non exportable key, lets name id S-KEY
  • each backup is wrapped with key=DKEK XOR-ed with S-KEY
    ?

That feature is already available. Using the Smart Card Shell you can clear the DKEK, preventing further imports and exports.

The DKEK management functions available in OpenSC (sc-hsm-tool) implement only a small part of the mechanisms available in the HSM. In projects we always use OpenSCDP tools to perform key management operations. In particular the Smart Card Shell and the scripting environment (e.g. the SmartCardHSM class), OCF and the Java JCE-Provider always support the full set of features.

Adding advanced key management features to OpenSC is complicated, as OpenSC tries to be as generic as possible. That is why we maintain a separate PKCS#11 module , which implements support for specialties found in the product.

There is work underway to port the sc-hsm-tool from OpenSC into our own PKCS#11 module, adding more advanced key management operations.

Thank you sc-hsm.
We are fans of command line tools. Stupid question - can I use SCC3 only with text console, without GUI, X-Window and other staff that I don’t like? :-).

Great!
Let say that sc-hsm-tool will stay CLI tool, without GUI.
Are you going to make available source of your own PKCS#11 library?
When?
Thanks a lot, it is and will be great solution.

Our PKCS#11 module is available on Github under BSD-3 license.

And yes, you can use the Smart Card Shell in a command line environment.