Create Crypto token per YubiHSM2 Domain in EJBCA

[rmuehl]

I'm trying to seperate different keys by using domains in the HSM

I'm not sure, if the following should work or not.

• I added 3 authentication keys each in a different domain.
• I added asym/opaque keys for each domain
• I added 3 Crypto Tokens in EJBCA, each with the corresponding authkey for this domain.

I was expecting, that each Crypto Token can see the keys of the corresponding domain. But it isn't. All 3 Crypto Tokens are showing the same keys of the one that was created first.

Am I doing something wrong, or is this not possible with YubiHSM2?

[rmuehl]

From EJBCA Doku: The following an be done: Using multiple tokens in the same HSM (in different EJBCA crypto tokens) when exposed as different tokens/slots in PKCS#11.

I guess I'm right that yubihsm_pkcs11.so does only support 1 Slot?

[aveenismail]

If by one slot you mean the slot configured in the EJBCA configured files, that is correct.

However, what dictates what keys are visible is the domains of the authentication key. So your setup with 3 different keys, each in it's own domain, with a corresponding asym key in each of those domains, is correct. It should work.

Are you sure the PIN to open a pkcs11 session is correct for each cryptotoken? The PIN should be: 4 digits corresponding to the authentication key objectID in hex format followed by the password to open a session with that auth key. So if your authkey has ID 0x02 and the password is "foo123", the PIN would be "0002foo123"

[rmuehl]

Yes the Pins are correct. The EJBCA Doku says also: The following is not supported:

Using the same token/slot with multiple EJBCA crypto tokens

So if I understand this right, it will not work...

[rmuehl]

Maybe I'm missing the concept of using YubiHSMs with EJBCA. How is this designed to be used, if I can't use different domains in different EJBCA Crypto Tokens, and also not be able to use more then 1 YubiHSM at once? Do I need to run a PKI Server for each YubiHSM?

[aveenismail]

I'm trying to spin up my test EJBCA but I haven't run it for so long that I need to setup the whole thing again, so it's taking me some time to try out your solution.

In the meantime, I can say that if there is a limitation to using multiple crypto tokens with the same slot, I doubt that it's caused by the YubiHSM. Domains are specifically used to allow the division you are trying to achieve. So my bet would be to figure out how SunPKCS11 Provider handles the connection is with the PKCS11 module in this case.

When you say you have configured 3 cryptotokens, are they configured only on the Adminweb or in the conf files too? I'm wondering if you have something like the following in conf/web.properties, would it make a difference?

cryptotoken.p11.lib.201.name=YubiHSM2_1 cryptotoken.p11.lib.201.file=/path/to/yubihsm_pkcs11.so

cryptotoken.p11.lib.202.name=YubiHSM2_2 cryptotoken.p11.lib.202.file=/path/to/yubihsm_pkcs11.so

cryptotoken.p11.lib.203.name=YubiHSM2_3 cryptotoken.p11.lib.203.file=/path/to/yubihsm_pkcs11.so

If you'll be trying this out, don't forget to restart the application server after changing the conf file

[rmuehl]

I've already tried this, but it did't work.

Currently I'm trying this:

cp /usr/lib64/pkcs11/yubihsm_pkcs11.so /usr/lib64/pkcs11/yubihsm_pkcs11.so-1 cp /usr/lib64/pkcs11/yubihsm_pkcs11.so /usr/lib64/pkcs11/yubihsm_pkcs11.so-2

cryptotoken.p11.lib.201.name=YubiHSM2_1 cryptotoken.p11.lib.201.file=/usr/lib64/pkcs11/yubihsm_pkcs11.so

cryptotoken.p11.lib.202.name=YubiHSM2_2 cryptotoken.p11.lib.202.file=/usr/lib64/pkcs11/yubihsm_pkcs11.so-1

cryptotoken.p11.lib.203.name=YubiHSM2_3 cryptotoken.p11.lib.203.file=/usr/lib64/pkcs11/yubihsm_pkcs11.so-2

Now I can add 3 crypto tokens in ejbca with the different libs.

I still need to test out, if this is really working.

[rmuehl]

This doesn't work too. I can add them once, but as soon as I deactivate them and try to reactivate them again, I'm getting this:

WARN [org.cesecore.keys.token.PKCS11CryptoToken] (default task-3) Failed to initialize PKCS11 provider slot '0'.: java.io.IOException: load failed ... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_FUNCTION_REJECTED ...

Maybe it's because of this:

cat catoken.properties sharedLibrary=/usr/lib64/pkcs11/yubihsm_pkcs11.so slotLabelType=SLOT_NUMBER slotLabelValue=0

[aveenismail]

Sorry for the late response. I haven't succeeded in blowing life into my old EJBCA test setup so I won't be able to test this.

A colleague looked into this too and pointed out that while the YubiHSM supports what you are trying to achieve, the PKCS11 standard does not. According to the standards, PKCS11 only has one login state, so every time there is a new login with new credentials, this is the authentication used for all subsequent operations.

Having said that, he had managed to have 3 PKCS11 sessions open at the same time by replicating the connector line in the config file set in YUBIHSM_PKCS11_CONF (only using the http connector, no direct USB connection) 3 times and tweaking some tests we have to see if it works. However, we are unable to test how that can be translated into EJBCA configurations.

Can I ask what the purpose of having 3 different cryptotokens with different access? Can different EJBCA admins have access to different CAs/Cryptotokens?

[rmuehl]

We have a 3 level CA structure Root Intermediate Issue And a new 2 Level CA structure Root Issue

So one idea would be to have the Issuing CA "autoconnected" active for signing certs. And the Root/Intermediates to have "offline" - that means NOT autoconnected. To sign CRLs, an admin has to activate the ejbca token by hand and deactivate it afterwards.

So if an attacker gets access to the ejbca, he is not able to get the PIN for the Root/Intermediates.

Another option would be to use 2 different HSMs for Root/Intermediate and Issuing CAs.

[aveenismail]

A clarification: PKCS11 standard allows only one login state per slot. By replicating the connector line in the config file, we could get more than one PKCS11 slot, then it was possible to have different credentials to access the same YubiHSM using the same yubihsm_pkcs11 module. Again, we are unable to translate that to EJBCA configurations so I don't know if this is helpful at all.

Different HSMs would work, but it sounds to me that the Root/intermediate CA keys don't need to be accessed at the same time as the issuers' CA keys. If an admin would have to activate the cryptotoken, produce the signed CRLs, then deactivate it again, all manually, then they can reactivate the issuers' cryptotoken when they are done, no? Or do the issuer CAs need to still be operational during the CRL signing?

[aveenismail]

Actually, the YubiHSM can only perform one operation at a time even if there are multiple sessions open to it. So even if the issuer's cryptotoken was active, no certificates can be signed at the same time as the CRL is.

[rmuehl]

Indeed the issuers must be active all the time, cuz there's an ACME Server running also. Bottom line I can't go with 1 HSM with different domains, and also I'm screwed with 2 HSMs at the same time. The only way to achieve this would be setting up a second PKI server to handle the Root/Intermediate stuff. Or use a HSM from another manufacturer.

[aveenismail]

I'm not sure the cryptotoken would need to be inactive. Typically, when an operation is still going in the YubiHSM, the next one would be delayed, so basically, queued up. So at least from the YubiHSM standpoint, it won't cause an error.

May I ask why a second HSM is not an option?

[rmuehl]

A second HSM is an option. But I don't know how to put them into ejbca. I can start 2 yubihsm-connectors listening on different ports. But how do I configure the pkcs11 config?

cat /etc/yubihsm_pkcs11.conf connector = http://127.0.0.1:12345

[qpernil]

Can you make use of different slots in the same pkcs11 module ? That can be configured by simply repeating the 'connector' line in yubihsm_pkcs11.conf. (this is also how you would configure it to use two or more different yubihsm:s, but then with different connector urls)