Add SafeNet 5110+ FIPS token support

[metsma]

Checklist

• Documentation is added or updated
• New files have a LGPL 2.1 license statement
• PKCS#11 module is tested
• Windows minidriver is tested
• macOS tokend is tested

Signed-off-by: Raul Metsma [email protected]

[Jakuje]

If I read it right, the new ATR matches basically the IDPrime 930, but it does support EC?

In that case, I would propose to use some better name to differentiate from the "short" IDPrime ATRs. Your ATR almost matches the SC_CARD_TYPE_IDPRIME_GENERIC, which was added as part of #2812, where the token is referenced as eToken 5110. Is there a way to make it more generic ATR mask to match both of them? Tagging @jurajsarinay to have a look or get some clarification if his eToken supports EC or his ATR can be used for some simplification here.

[metsma]

I tried to match the generic but I am not sure if it supports ECC?
Product sheet states it is FIPS 140-2 compatible and supports ECC and RSA 4096.
Also it states, that is based on IDPrime 930 platform.
https://data-protection-updates.gemalto.com/2022/07/20/safenet-etoken-5110-fips-release-announcement/
https://www.qscd.eu/tips-tricks/what-is-the-difference-between-5110--and-5110cc--940--gemalto-safenet-etoken/#

[jurajsarinay]

If I read it right, the new ATR matches basically the IDPrime 930, but it does support EC?

In that case, I would propose to use some better name to differentiate from the "short" IDPrime ATRs. Your ATR almost matches the SC_CARD_TYPE_IDPRIME_GENERIC, which was added as part of #2812, where the token is referenced as eToken 5110. Is there a way to make it more generic ATR mask to match both of them? Tagging @jurajsarinay to have a look or get some clarification if his eToken supports EC or his ATR can be used for some simplification here.

My token does support EC and works if I treat it as SC_CARD_TYPE_IDPRIME_940 instead of SC_CARD_TYPE_IDPRIME_GENERIC.

Within card-idprime.c, SC_CARD_TYPE_IDPRIME_930_2 behaves the same as SC_CARD_TYPE_IDPRIME_940. A simplification that treats both the ATRs as SC_CARD_TYPE_IDPRIME_940 might work:

diff --git a/src/libopensc/card-idprime.c b/src/libopensc/card-idprime.c
index 231a8d248..d13df07f2 100644
--- a/src/libopensc/card-idprime.c
+++ b/src/libopensc/card-idprime.c
@@ -58,9 +58,9 @@ static const struct sc_atr_table idprime_atrs[] = {
          "Gemalto IDPrime 930/3930",
          SC_CARD_TYPE_IDPRIME_930, 0, NULL },
        { "3b:ff:96:00:00:81:31:fe:43:80:31:80:65:b0:84:65:66:fb:12:01:78:82:90:00:85",
-         "ff:ff:00:ff:ff:ff:ff:00:ff:ff:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:00",
+         "ff:ff:00:ff:ff:ff:ff:00:ff:ff:ff:ff:ff:ff:00:00:00:00:ff:00:00:ff:ff:ff:00",
          "based Gemalto IDPrime 930",
-         SC_CARD_TYPE_IDPRIME_930_2, 0, NULL },
+         SC_CARD_TYPE_IDPRIME_940, 0, NULL },
        { "3b:7f:96:00:00:80:31:80:65:b0:85:59:56:fb:12:0f:fe:82:90:00",
          "ff:ff:00:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:ff:00:00:ff:ff:ff",
          "Gemalto IDPrime 940",
@@ -77,10 +77,6 @@ static const struct sc_atr_table idprime_atrs[] = {
          "ff:ff:00:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:ff:00:00:ff:ff:ff",
          "Gemalto IDPrime MD 8840, 3840, 3810, 840, 830 and MD 940 Cards",
          SC_CARD_TYPE_IDPRIME_GENERIC, 0, NULL },
-       { "3b:ff:96:00:00:81:31:fe:43:80:31:80:65:b0:85:59:56:fb:12:0f:fe:82:90:00:00",
-         "ff:ff:00:ff:ff:ff:ff:00:ff:ff:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:00",
-         "Gemalto IDPrime MD 8840, 3840, 3810, 840 and 830 Cards",
-         SC_CARD_TYPE_IDPRIME_GENERIC, 0, NULL },
        { NULL, NULL, NULL, 0, 0, NULL }
 };

I originally copied the mask and the description from smartcard-list.txt. I do not know which other cards it matches.

[metsma]

First I tried to match SC_CARD_TYPE_IDPRIME_940 atr, but there are couple cases where it breaks.
This device does not have 0005 file
https://github.com/OpenSC/OpenSC/pull/3048/files#diff-1892ee089e440f54f73abfe799748d7cdbdf540419ae7898086382caeb395b43L582

And also I am not sure the key_reference arithmetic? how I can verify my device correct key_reference
https://github.com/OpenSC/OpenSC/pull/3048/files#diff-1892ee089e440f54f73abfe799748d7cdbdf540419ae7898086382caeb395b43L455
Maybe I can use the 940 key_reference case here
https://github.com/OpenSC/OpenSC/pull/3048/files#diff-1892ee089e440f54f73abfe799748d7cdbdf540419ae7898086382caeb395b43L457

[metsma]

Token category: Hardware
Reader name: SafeNet eToken 5110+ FIPS 0
Serial number (PKCS#11): ....
Free space: 53788
Card ID (GUID): 0x...
Product name: eToken 5110+ FIPS
Card type: IDPrime
Applet Version: IDPrime Java Applet 4.5.0.F
Mask version: G286
Token Password: Present
Token Password retries remaining: 5
Maximum Token Password retries: 5
Token Password expiration: No expiration
Administrator Password: Present
Administrator Password retries remaining: 5
Maximum administrator Password retries: 5
FIPS: FIPS 140-2 L2
Full Secure Messaging (SM): No
Sign padding on-board: Yes
Supported key size: 4096 bits
ECC: Supported
CSP: eToken Base Cryptographic Provider
KSP: SafeNet Smart Card Key Storage Provider

[Jakuje]

And also I am not sure the key_reference arithmetic? how I can verify my device correct key_reference

Usually by running the pkcs11-tool --test or p11test with the token and having more than one keys on the token loaded. The tools do signature+verification process and if the key identifier would not match the calculation, the signature would either fail (if wrong key reference would be used) or the signature verification would fail (if the key reference matching different key than we think would be used).

[metsma]

Seems like this test is RSA only

pkcs11-tool --test
Using slot 0 with a present token (0x0)
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  seems to be OK
Digests:
  all 4 digest functions seem to work
Failed to load legacy provider
Ciphers: not implemented
Signatures (currently only for RSA)
Signatures: no private key found in this slot
Verify (currently only for RSA)
  No private key found for testing
Unwrap: not implemented
Decryption (currently only for RSA)
No errors

[Jakuje]

Yes, pkcs11-tool test supports only RSA. If you want more extensive tests, I can recommend the p11test in src/tests/p11test (not packaged, needs to be built from source).

[metsma]

I received today ECC certificates for this device and I can confirm ECC signing works.
Started looking the code and seems like ECC dervice is not implemented?

[metsma]

Seems like signing works in my computer. I will let test this our test team.
Regarding ECC key derive, it does not work with SAC tools either.

[Jakuje]

Whats is the status of this PR? Is there some simplification that can be implemented, or should we consider this as final?

If I see right, the only difference from SC_CARD_TYPE_IDPRIME_930 to SC_CARD_TYPE_IDPRIME_930_2 is that for the _2 you add the EC support. I think I had only one 930 without EC keys, but they are likely supported so I would propose to avoid adding the _2 and just use the SC_CARD_TYPE_IDPRIME_930 and add the EC support to that.

[metsma]

Whats is the status of this PR? Is there some simplification that can be implemented, or should we consider this as final?

If I see right, the only difference from SC_CARD_TYPE_IDPRIME_930 to SC_CARD_TYPE_IDPRIME_930_2 is that for the _2 you add the EC support. I think I had only one 930 without EC keys, but they are likely supported so I would propose to avoid adding the _2 and just use the SC_CARD_TYPE_IDPRIME_930 and add the EC support to that.

Does it support RSA 4k? If so I can merge these two

[Jakuje]

Whats is the status of this PR? Is there some simplification that can be implemented, or should we consider this as final?
If I see right, the only difference from SC_CARD_TYPE_IDPRIME_930 to SC_CARD_TYPE_IDPRIME_930_2 is that for the _2 you add the EC support. I think I had only one 930 without EC keys, but they are likely supported so I would propose to avoid adding the _2 and just use the SC_CARD_TYPE_IDPRIME_930 and add the EC support to that.

Does it support RSA 4k? If so I can merge these two

Looking at the card I have, we already have there some EC keys so EC keys is ok to add. We do not have 4k keys there, but I believe it should support them too. So lets merge them.

[metsma]

Whats is the status of this PR? Is there some simplification that can be implemented, or should we consider this as final?
If I see right, the only difference from SC_CARD_TYPE_IDPRIME_930 to SC_CARD_TYPE_IDPRIME_930_2 is that for the _2 you add the EC support. I think I had only one 930 without EC keys, but they are likely supported so I would propose to avoid adding the _2 and just use the SC_CARD_TYPE_IDPRIME_930 and add the EC support to that.

Does it support RSA 4k? If so I can merge these two

Looking at the card I have, we already have there some EC keys so EC keys is ok to add. We do not have 4k keys there, but I believe it should support them too. So lets merge them.

Done

[Jakuje]

@xhanulik is this good to go to the 0.25.0?

[xhanulik]

@xhanulik is this good to go to the 0.25.0?

Yes, I think so.