sc-hsm-tool --create-dkek-share file.pbe gives output as follows:
Please keep the generated DKEK share file in a safe location. We also recommend to keep a paper printout, in case the electronic version becomes unavailable. A printable version of the file can be generated using “openssl base64 -in ”.
Sorry, but I don’t understand “paper printout” recommendation. I bought HSM2 for REAL, hardware, two factor security (something I have- HSM2, something I know - PIN). Putting all secrets on paper is … strange for me.
If I bought TWO HSM 2, is it good idea to backups/restore ECC/RSA keys from 1-st HSM 2 to 2-nd HSM 2, and write down *. pbe file(s) to BOTH HSM2 (1-st and 2-nd)? As follows:
note --private option: object (file) is only viewable after a login). And than destroy all files outside of HSM2 and destroy all “paper printout” (if any).
If one of my two HSM2 will fail in the future, I can read dkek-shares and do another backup/restore. Am I right?
What do you think about advantages and disadvantages of writting dkek-shares to HSM2 (with --private flag of course).
What about using for scenerio above other flags like --extractable
or --always-auth.
–sensitive is not an option because we need in the future dkek-shares in plaintext, without wrap.
This does not answer most of your question, but for anyone concerned about the security of printers (many of which have hard drives nowadays and may save whatever is printed), I suggest to base32-encode the file and write it down on paper – it is only 104 characters.
Edit: I think the disadvantage that anyone who has the PIN can get to your DKEK backup (and then try to crack the password) may be undermining some of the security of using the HSM. After all “give a HSM to someone so that person can sign/encrypt/decrypt, but never gets the private keys” is among possible use cases for a HSM.
The DKEK share is actually password protected. The recommendation to print the encrypted DKEK share is just a reminder, that without the encrypted share the password is pretty much useless.
The actual DKEK share imported is a 128 bit random value. Such a high entropy is difficult to memorize as password. And remember, it’s actually the DKEK that protects your keys outside the HSM, not the DKEK share password.
If you are looking for pure backups on other HSM device, then I’d recommend to take a look at XKEK key domains. There the Key Exchange Key between two HSMs is a random key and there is no practical way to obtain the plain way of such a key. All key only exists within the closed Key Domain.
We usually recommend to use DKEK Key Domain with a strong organizational key management protocol for Root-CA keys and XKEK key domains if mechanisms like backup/recovery and key escrow are required.
I don’t understand. If DKEK is 256 bits, and we use DKEK shares to compute DKEK with XOR, DKEK shares length should be equal length of DKEK (256 bits, not 128 bits), because XOR function output length is equal XOR function arguments length:
N-bits XOR N-bits gives N-bits outputs.
For two DKEK shares, lets say:
DKEK_shares_1, and
DKEK_shares_2 what is true:
DKEK = DKEK_shares_1 ^ DKEK_shares_2
or
DKEK = DKEK_shares_1 . DKEK_shares_2
or something else?
where ^ is C lang XOR operator
. is concatenation
I have no idea how to receive 256 bits long DKEK from 128 bits DKEK shares.
