Use Case
Foundries Factory Open Source IoT & Device Management Platform | Foundries.io is currently not able to use several root-ca’s on one HSM (due to the same label) and I am just wondering if it is possible to have another or mutiple DKEK on the HSM which might be then used to create the root-ca.
I was seeing only that the initialization with dkek-shares deletes everything else.
Test scenario
sc-hsm-tool -r 1 --initialize --so-pin 3537363231383830 --pin 648219 --dkek-shares 1
sc-hsm-tool -r 1 --create-dkek-share 2024-06-04_dkek-share.pbe --pwd-shares-threshold 3 --pwd-shares-total 5
sc-hsm-tool -r 1 --import-dkek-share 2024-06-04_dkek-share.pbe --pwd-shares-threshold 3
sc-hsm-tool -r 1 --create-dkek-share 2024-07-01_dkek-share.pbe --pwd-shares-threshold 3 --pwd-shares-total 5
sc-hsm-tool -r 1 --import-dkek-share 2024-07-01_dkek-share.pbe --pwd-shares-threshold 3
prompts to “Enter passwort do decrypt DKEK share” which is wrong since it is a DKEK with N-of-m schema. Should create an error message right? Since the dkek-share limit/goal was reached.
Smart Card Shell shows only one DKEK
Thanks @nku using already SCS 3.18.12
After User PIN Login I get the option to create a DKEK or XKEK Domain.
Creating a DKEK Key Domain the option “Enter number of DKEK shares” is presented.
Btw. I found a bug, a not so good UX or more likey an unsupported feature.
When selecting 1 and selecting Import DKEK Share > Import DKEK Share from File and selecting a pbe n-m schema created with sc-hsm-tool SCS is asking for a password instead of the prime, id and so on. Creating a DKEK file with SCS I can only choose a password…
Back to topic
After DKEK set-up in progress with 1 of 1 share or with imported DKEK share, I cannot select to create another DKEK or XKEK Domain.
Delete Key Domain brings me back to Create DKEK/XKEK Key Domain
The SmartCard-HSM supports up to 255 key domains, which can be either the DKEK or XKEK variant. You need to configure the maximum number of key domains during initialization. The default set in the Smart Card Shell’s Key Manager, is to reserve space for 4 key domains.
Once you allocated space for key domains, you can create, configure, use and remove them.
The sc-hsm-tool from OpenSC does not support multiple key domains, as this tool was designed for the 1.x release of the product. On the other side, the Smart Card Shell does not support n-of-m DKEK shares. We need to add support for multiple key domains in sc-hsm-tool and n-of-m DKEK shares in the Key Manager.
using SCS I can only create one DKEK or XKEK or did I overlooked something?
One import with a n-of-m DKEK share would be possible via the sc-hsm-tool to be prepared for the future when sc-hsm-tool is supporting multiple key domains
With the Smart Card Shell you can initialize for more than one key domain and then manage all of them. The maximum number of key domains allowed is an initialization parameter, that can not be set using the sc-hsm-tool.
Currently you can not import a n-of-m DKEK share, but we just added the basic Shamir Shared Secret support that and it will be available in the Key Manager soon.
On Windows please use the SCSH version that is bundled with the JRE. We can not test all the possible combinations of Windows version, OpenJDK versions and local modifications.
To import a DKEK share created with sc-hsm-tool using n-of-m, please use “Import DKEK Share from File (n-of-m)”. The is no mechanism in the Smart Card Shell yet to generate DKEK shares protected by n-of-m. You still need to use the sc-hsm-tool, if you want to use that.
ok. SCS is working with the Temurin JRE Version.
Seeing your bundle is using Temurin 17.0.11.+9
Tried to install the “old” version 3.18.29 via the installer and it hangs now also on step 4 but I will not investigate since after quitting the installer, SCS is working.
Either way thank you for your fast implementation. Now I am able to test my use case.
I wasn’t successful.
Initialized HSM 2 with Device Encryption scheme: Key Domains < fioctl stored the root-ca in root and not in a DKEK.
Initialized HSM 2 with Device Encryption scheme: DKEK Shares < fioctl stored the root-cat within the DKEK
fioctl uses pkcs11-tool I guess this also does not support key domains?
PKCS#11 and pkcs11-tool have no mechanism to select the key domain in which the key shall be generated.
The “old” initialization variant in sc-hsm-tool configures the HSM to have a single DKEK key domain. All keys are automatically associated with that domain.
Can you tell Fioctl to use an existing key ? That way you could generate the key in the SCSH and define all the attributes required.
I would try to generate a key using exactly that label and id and see how fioctl handles the failing pkcs11-tool, if that key already exists.
If that does not work, then you could just disable the pkcs11-tool invocation, as the key specification should work for an externally generated key as well.
It’s generally a good advice for tools creating a CA: The important information is the key and using an already existing key (which might be from a previous configuration or restore) should always be possible.
It also not a good design to use pkcs11-tool, rather than integrating at the PKCS#11 level. The pkcs11-tool is meant as a development tool and is not a stable API.
fioctl is not able to create a ca when the label ‘root-ca’ is already on the token. Therefore I though handling it with several DKEK it may be possible…
In Q3/Q4 foundries wants to implement the feature to renew the root-ca.
I am not able to provide an existing key for root-ca creation but will ask them.
Can you please elaborate more on the “disable pkcs11-tool invocation”
Even if you configure multiple key domains, you still have an unique name space for labels and ids. The association of a key with a key domain is solely an attribute of the key. This is the normal PKCS#11 data model, where a token represents a collection of keys that are protected by the same authentication mechanism.
If your issue is, that you want to avoid name clashes by using multiple key domains, than that will not work.
Usually in PKCS#11 the label (CKA_LABEL) is a user related piece of information, while the id (CKA_ID) is somethings systems use to locate keys. Ideally CKA_ID is an unique representation of the key value, like a Key Check Value for symmetric keys or the Subject Public Key Identifier that is usually contained as a certificate extension.
Our recommended approach to generating keys, is to use C_GenerateKeyPair(), read the public key and determine the Subject Public Key Identifier, then change an automatically generated CKA_ID to the SPKI. With OpenSC, the CKA_ID is already automatically generated as SPKI, if no CKA_ID is given. But other HSMs may do that differently. CKA should then be something the user can recognize, like a name with version and date.
Can you please elaborate more on the “disable pkcs11-tool invocation”
Usually setting up a CA consists of the key pair generation and the issuing of the self-signed root certificate. If you allow to skip the first step, you can reuse an already existing key, if the key handle is the same.
