Card misidentification

[msetina]

Running OpenSC 0.25.1:
Got two cards:
ATR: 3b:7f:96:00:00:80:31:80:65:b0:85:59:56:fb:12:0f:fe:82:90:00
and
ATR: 3b:7f:96:00:00:80:31:80:65:b0:85:03:00:ef:12:0f:fe:82:90:00

Both identify as Gemalto IDPrime 940.

Code

[Jakuje]

From the source code, the second should be identified as 840, but it looks like the mask overlaps since #2958.

OpenSC/src/libopensc/card-idprime.c

Lines 72 to 75 in 26b9067

	{ "3b:7f:96:00:00:80:31:80:65:b0:85:03:00:ef:12:0f:fe:82:90:00",
	"ff:ff:00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:ff:ff:ff",
	"Gemalto IDPrime 840",
	SC_CARD_TYPE_IDPRIME_840, 0, NULL },

Is it correct that it should be 840?

The workaround might be to change the order of the masks.

[msetina]

Yes, one should be 840. The other is OK to be 940. I am not familiar with the masks usage.

[msetina]

If I understand properly the mentioned PR turned off the bits that identify the card. What was the reason @Nihlus ?

[Jakuje]

If I understand properly the mentioned PR turned off the bits that identify the card. What was the reason @Nihlus ?

No, it set the mask to 0x00, which means any bits match there. It looks like something we overlooked and I think just changing order of the entries should solve the issue. But we will need to test it with various cards ...

[msetina]

I have 940 and 840. Will try changing order.

[msetina]

But this also means that 940 and 940C overlap.

[msetina]

Changing order fixes identification, but it uncovered that 840 does not have EC support. Specs say:

Encryption algorithms:
RSA: up to RSA 2048 bits, RSA OAEP & RSA PSS, elliptic curves: P-256, P-384, P-521 bits, ECDSA, ECDH, (RSA & Elliptic) 3DES (ECB, CBC), AES (128, 192, 256 bits),
Hash functions:
Hash: SHA-1, SHA-256, SHA-384, SHA-512
Memory size:
80 kB, up to 15 containers for storage of encryption keys (RSA, elliptic curves)
Data storage in memory:
25+ years
Memory overwriting:
at least 500.000 cycles
Operating conditions:
T=0, T=1, PPS, with baud up to 230 Kbps

[msetina]

This is set just for 930 and 940, but it is also usable for MD 840:

OpenSC/src/libopensc/card-idprime.c

Lines 656 to 665 in 26b9067

	/* Set up algorithm info for EC */
	flags = SC_ALGORITHM_ECDSA_RAW | SC_ALGORITHM_ECDSA_HASH_NONE;
	ext_flags = SC_ALGORITHM_EXT_EC_F_P
	| SC_ALGORITHM_EXT_EC_ECPARAMETERS
	| SC_ALGORITHM_EXT_EC_NAMEDCURVE
	| SC_ALGORITHM_EXT_EC_UNCOMPRESES
	;
	_sc_card_add_ec_alg(card, 256, flags, ext_flags, NULL);
	_sc_card_add_ec_alg(card, 384, flags, ext_flags, NULL);
	_sc_card_add_ec_alg(card, 521, flags, ext_flags, NULL);

[msetina]

I am not sure about the ext_flags.

[Nihlus]

Yeah, I just updated the mask so that the 940 card I had passed (enabling the bits that differed). I don't have any other IDPrime cards to test with, so I went with the naive approach. Changing as previously suggested seems like a fair option.

[Jakuje]

@msetina do you want to submit a PR with your changes getting the 940 card detected correctly?

[msetina]

I was wondering why this card driver does not support key generation.

[Jakuje]

Because nobody implemented it. There is no specification for this applet.

If you would like to capture the APDU trace of official driver while generating keys and implement it into opensc, we would be happy to take your patches. But so far we had quite enough work to get the card detection and readonly operations right (as you can see).