0

I am trying to utilize the SafeNet eToken 5110CC, which basically has the IDPrime 940MD with the applet 4.4.2.A., to generate ECC keys with lengths 384bits and 521bits to no avail.

The product brief says that ECDSA and ECDH of 384/521bits are supported through "custom configuration", but they are supported.

Before asking this question, I have tried contacting THALES, but, of course, they wouldn't accept helping without a contract or direct business relation and suggested I contact the reseller (who, again, stopped responding and I highly doubt they would be able to help anyway).

To generate the ECC384/521 I have first tried through both the minidriver and the KSP, and I get an error of "missing elements", even though the Windows Certificate Store does show the 384/521 options when requesting a custom CSR. The ECC256 works like a charm.

I am currently trying to use OpenSC with the PKCS#11 module (eToken.dll or eTPKCS11.dll). I have already tried the pkcs11-spy module, and I am attaching the results here.

I have, among others, tried:

  1. pkcs11-tool --module "C:\Program Files\OpenSC Project\PKCS11-Spy\pkcs11-spy.dll" --keypairgen --key-type EC:secp384r1
  2. pkcs11-tool --module "C:\Program Files\OpenSC Project\PKCS11-Spy\pkcs11-spy.dll" -m "ECDSA-KEY-PAIR-GEN" --keypairgen --key-type EC:secp384r1

When I tried, just in case, to check with unsupported curves/random letters, I indeed realized that the module does recognize the curves, and the problem seems to be elsewhere:

  1. Unsupported curve (such a curve doesn't exist):

error: Unknown EC key params 'secp384'

  1. Supported curve:

error: PKCS11 function C_GenerateKeyPair failed: rv = CKR_ATTRIBUTE_VALUE_INVALID (0x13)

pkcs11-spy results:

  1. Successful generation of ECC256:

[...] 11: C_GenerateKeyPair 2022-01-27 19:55:21.298 [in] hSession = 0x260001 [in] pMechanism->type = CKM_EC_KEY_PAIR_GEN [in] pMechanism->pParameter[ulParameterLen] NULL [size : 0x0 (0)] [in] pPublicKeyTemplate[7]: CKA_CLASS CKO_PUBLIC_KEY
CKA_TOKEN True CKA_VERIFY True CKA_DERIVE True CKA_EC_PARAMS 000002045ba63790 / 10 00000000 06 08 2A 86 48 CE 3D 03 01 07 ..*.H.=...
CKA_KEY_TYPE CKK_EC
CKA_PRIVATE False [in] pPrivateKeyTemplate[7]: CKA_CLASS CKO_PRIVATE_KEY
CKA_TOKEN True CKA_PRIVATE True CKA_SENSITIVE True CKA_SIGN True CKA_DERIVE True CKA_KEY_TYPE CKK_EC [out] hPublicKey = 0xdc4000c [out] hPrivateKey = 0x6dd000b Returned: 0 CKR_OK [...]

  1. Unsuccessful ECC384:

[...] 9: C_GenerateKeyPair 2022-01-27 19:55:43.063 [in] hSession = 0x260001 [in] pMechanism->type = CKM_EC_KEY_PAIR_GEN [in] pMechanism->pParameter[ulParameterLen] NULL [size : 0x0 (0)] [in] pPublicKeyTemplate[7]: CKA_CLASS CKO_PUBLIC_KEY
CKA_TOKEN True CKA_VERIFY True CKA_DERIVE True CKA_EC_PARAMS 0000012e1c60c6e0 / 7 00000000 06 05 2B 81 04 00 22 ..+..."
CKA_KEY_TYPE CKK_EC
CKA_PRIVATE False [in] pPrivateKeyTemplate[7]: CKA_CLASS CKO_PRIVATE_KEY
CKA_TOKEN True CKA_PRIVATE True CKA_SENSITIVE True CKA_SIGN True CKA_DERIVE True CKA_KEY_TYPE CKK_EC Returned: 19 CKR_ATTRIBUTE_VALUE_INVALID

10: C_Finalize 2022-01-27 19:55:43.063 Returned: 0 CKR_OK [...]

Any pointers to what I'm doing wrong?

Second question: Regarding the Integrated Circuit Certificate (ICC) and Card Verifiable Certificate (CVC), how do I access that information whether a ket was generated on-board? I haven't found any mechanism similar to TPM Attestation or Yubico's Attestation. Supposedly, for the Safenet Luna HSM there is an integrated command in the SDK to verify the authenticity. There must be a way for the same to be done on the eToken 5110CC. How would someone e.g. verify a CSR was indeed generated by the token or that the token they bought is indeed genuine?

schroeder
  • 123,438
  • 55
  • 284
  • 319
ARGYROU MINAS
  • 111
  • 1
  • 10
  • The product brief doesn't say _end-user_ configuration – it could just as well refer to the customer requesting a different hardware configuration or different firmware as part of their order... – user1686 Jan 28 '22 at 13:38
  • Then that would be a misleading product brief, especially with EU regulations. Regardless, I don't think that the firmware is limited in any way. I have found out that DigiCert uses the 5110CC version for the EV Code Signing and they explicitly say that ECC 384 can be used or RSA 3072/4096. If DigiCert does it on a BOYD token, then it must be somehow available. DigiCert uses their own Hardware Certificate Installer though, which I didn't manage to install (doesn't let me "agree" to the EULA). – ARGYROU MINAS Jan 28 '22 at 13:55
  • Regardless of the DigiCert case where they explicitly said they can generate ECC 384bit on the 5110CC token, even if I source it myself, I just got a response from a reseller and they said that for 384/521bit the token must be "ordered from the factory" that way and the tokens they provide don't do it... even though they advertise it as available on their product listing. But how would DigiCert do it? That is what leads me to believe that there is a way... – ARGYROU MINAS Jan 28 '22 at 16:27

0 Answers0