For me it is described not precise enough in the documentation.
But do I understand it right? For example 2 HSM devices.
Device 1 and 2: initialize each by
sc-hsm-tool -X --dkek-shares 1
Device 2 - create DKEK share
sc-hsm-tool --create-dkek-share dkek-share-1.pbe
Device 1: import the DKEK share created by device 2
sc-hsm-tool --import-dkek-share dkek-share-1.pbe
When I currently have only one device but later want to add a second, can this be done by creating the dkek-share on device 1 and initialize it with 1?
Or would that be the same like using --dkek-shares 0 ?
I already was on that page. But for me the role of the dkek-share is still unclear.
Is it only another way of “password protection”.
So it’s on my own if I create one or two or three dkek-shares. The only difference is, that all of the specified number of dkek-shares have to be present for export/import?
The DKEK Share’s purpose is to establish a logical security domain. Several devices can be added to one security domain. All devices which are part of the security domain can securely backup and import actual keys. Backups will be encrypted with the DKEK share and not with passwords.
The Device Key Encryption Key (DKEK) is an AES-256 key stored in the SmartCard-HSM. It is used to securely export or import key material.
The questions is: Where does that key come from ? The DKEK Share is the answer. The final DKEK in the SmartCard-HSM is assembled from DKEK shares in a XOR operation. After you initialize the device, a temporary buffer is initialized with all 00. Then you import the first DKEK share and that is updating the buffer in an XOR operation. Then you import the next DKEK share and again the value in the buffer is XORed. After you have imported all shares, the final DKEK value is in the buffer is the result of performing XOR operations on all DKEK shares. That way the confidentiality of the DKEK is maintained by splitting the secret in n-XOR shares.
Of course each DKEK share contains a part of the final secret, so that must be kept confidential as well. One way could be, that the key custodian himself creates a password with 256 bit entropy. That is however not really feasible. Instead the sc-hsm-tool generates a DKEK share using the random number generator in the SmartCard-HSM and then encrypts the DKEK share using a password supplied by the key custodian. That way the entropy of the supplied password can be lower that the actual DKEK share.
An adversary needs both, the encrypted DKEK share file and the password. And that from all key custodians involved in creating the DKEK.
Additionally, access to the DKEK share can be controlled by a n-of-m threshold scheme. So rather than providing a password to decrypt the DKEK share, n of the m assigned key custodians must present their password to decrypt the DKEK share.
